Forums & community:FwpmNetEventEnum5 have a lot of memory leak in windows10

Question

After executing FwpmNetEventEnum5, there is a lot of memory leak after calling FwpmFreeMemory0.

The current operating system version is windows 10.0.19042

And I have raised the bug in the GitHub sample：https://github.com/microsoft/Windows-classic-samples/issues/202

Answer 1

Hello All,

There is indeed a memory leak in the FwpmNetEventEnum routines. These routines use RPC to the BFE service and assume that the returned events are all laid out in a single buffer (ACF attribute [allocate(all_nodes)]) but this is not the case. Applying FwpmFreeMemory to the returned events just frees the array of pointers to the individual events.

One option is to ignore the documentation ("The returned array of entries (but not the individual entries themselves) must be freed by a call to FwpmFreeMemory0") and to explicitly free every pointer in the returned array of events. There are however two complicating factors:

1. Only the "newest" routine (FwpmNetEventEnum5) directly calls the RPC routine; the older routines (e.g. FwpmNetEventEnum4) call FwpmNetEventEnum5 and then repackage the returned data in data structures appropriate to the older routine. A pointer to the original FwpmNetEventEnum5 result is not returned to the application and the older routine just uses a single FwpmFreeMemory0 to free the FwpmNetEventEnum5 result and therefore leaks the same amount of memory as every other FwpmNetEventEnum5 invocation.
2. As can been seen from the output of the command netsh wfp show netevents, there is some "internal" data appended to each event and the representation of some of this internal data uses pointers (e.g. filterOrigin and terminatingFiltersInfo) and one would have to deduce the layout/location of this internal information in order to locate (and free) all of the embedded pointers.

Another option might be to accept the memory leakage for a single invocation of FwpmNetEventEnum and then use FwpmNetEventSubscribe to receive new events - this uses a different RPC routine to receive the events and does not seem to suffer from the same embedded pointer problem.

Gary

Answer 2

Issue is resolved using RPC_C_AUTHN_WINNT to open the engine. If RPC_C_AUTHN_DEFAULT is used, the call to free the memory from the enumerated events fails silently.

EDIT It's not resolved, my mistake. You still mus create a new process and tear it down periodically.

Answer 3

After replacing FwpmNetEventEnum0 with FwpmNetEventEnum5, I did not find memory leak in diagevents sample but I used an invalid remoteAddr. My windows10 OS build is 19042.928.