Hello everyone.
My Ndis filter driver works fine, but poolmon doesn't display any pool that I allocated with NBLPoolHandle = NdisAllocateNetBufferListPool ()
and
NBPoolHandle = NdisAllocateNetBufferPool ()
and is used with
NdisAllocateCloneNetBufferList(pNBL, NBLPoolHandle , NBPoolHandle,0 )
What is the reason?
Is it possible that Ndis is changing the pool Tag and I can't find them in Poolmon?
Thank You.
Please show the definition of your pool tag in code.
Inside FilterAttach:
NET_BUFFER_LIST_POOL_PARAMETERS ParametersNBL_S;
NdisZeroMemory(&ParametersNBL_S, sizeof(NET_BUFFER_LIST_POOL_PARAMETERS));
ParametersNBL_S.Header.Revision = NET_BUFFER_LIST_POOL_PARAMETERS_REVISION_1;
ParametersNBL_S.Header.Type = NDIS_OBJECT_TYPE_DEFAULT;
ParametersNBL_S.Header.Size = sizeof(NDIS_SIZEOF_NET_BUFFER_LIST_POOL_PARAMETERS_REVISION_1);
ParametersNBL_S.ProtocolId = NDIS_PROTOCOL_ID_DEFAULT;
ParametersNBL_S.ContextSize = MEMORY_ALLOCATION_ALIGNMENT;
ParametersNBL_S.PoolTag = 'NBLS';
ParametersNBL_S.fAllocateNetBuffer = FALSE;
ParametersNBL_S.DataSize = 0;
ParametersNBL_S.Flags = NET_BUFFER_LIST_POOL_FLAG_VERIFY;
pFilter->snd.NBLPoolHandle = NdisAllocateNetBufferListPool(NdisFilterHandle, &ParametersNBL_S);
NET_BUFFER_POOL_PARAMETERS ParametersNB_S;
NdisZeroMemory(&ParametersNB_S, sizeof(NET_BUFFER_POOL_PARAMETERS));
ParametersNB_S.Header.Revision = NET_BUFFER_POOL_PARAMETERS_REVISION_1;
ParametersNB_S.Header.Type = NDIS_OBJECT_TYPE_DEFAULT;
ParametersNB_S.Header.Size = sizeof(NDIS_SIZEOF_NET_BUFFER_POOL_PARAMETERS_REVISION_1);
ParametersNB_S.PoolTag = 'NBMS';
ParametersNB_S.DataSize = 0;
ParametersNB_S.Flags = NET_BUFFER_POOL_FLAG_VERIFY;
pFilter->snd.NBPoolHandle = NdisAllocateNetBufferPool(NdisFilterHandle, &ParametersNB_S);
Inside FilterSendNetBufferLists:
PNET_BUFFER_LIST cloneNBL = NdisAllocateCloneNetBufferList(pNBL, pFilter->snd.NBLPoolHandle, pFilter->snd.NBPoolHandle, (ULONG)0);
You did look for the reverse order strings, right?
I know that. But in reverse order it is the same. There are no allocations from nbls nor slbn pools. Thank You. In poolmon I see meny nbl1, nbl2, nbl3 pools, but I thing, these are not mine
I found a solution. My tags need to be added to the pooltag.txt file.
now i see, when i uninstall driver, some allocations from non paged pool remains in memory, so the driver does not uninstalling. How to free leaked allocations by hand
What do you mean, “by hand”? If your driver allocated memory, then it is 100% your driver’s responsibility to free that memory. And dangling non-paged pool allocations will not prevent a driver from unloading. The operating system has no idea which driver allocated which memory.
Driver Verifier can do that, by intercepting the calls. Are you running Driver Verifier?
reference leaks prevent driver unload, but leaked allocations don’t. Leaked allocations can be caused by reference leaks because cleanup is never called. Both are major issues that no release quality driver is expected to have
Saying by hand I meant if there is an instrument, with the help of what I can free unreleased pools at the time, when driver is trying to be detach. In detach function of filter driver I have freed all pools, without freeing separate allocations inside them. Of course the references to these allocations are remain outstanding. Thank You very much.
I know, that this is not a right place for my question, but in any case, i want to ask. I have a user mod console program, that is working with ndis filter driver. It consist from tree threads: main thread, thread that works with receive path and thread working with send path of driver. When i pressing the close button on the console of my user program, the receive thread is terminating, but send thread and main threads remains active. I see it with process.exe. Why the send thread is not terminating. After i tried to intercept console notification handler. Now When i close console program, notification handler is called but after some time, when i am still inside that handler (with visual studio debugger) happens the same. Receive thread terminated, other two threads remain. I thing, that everything must terminate only after when handler function will return.
You said “pressing the close button on the console”. Do you mean literally closing the console window? That’s clearly the wrong way to exit a console app. Does Ctrl-C work?
As a rule, you should have a mechanism to signal your threads to exit. You said that the “main thread remains active”. Why is that? Your process will not end until the main thread exits.
The documentation states that CreateThread, ExitProcess and ExitThread are all serialized. Perhaps your handler is being called in the ExitProcess case, which means ExitThread won’t run until your handler returns.
As Tim know, process destruction is more complex than what he describes.
The ‘main’ thread of a process is usually just the first one created. Some versions of the CRT call ExitProcess when the version of the main function that the compiler used returns. Others don’t. If you aren’t using C or C++, the CRT doesn’t apply. There is a long list of consideration, but ultimately all of the threads of the process must exit, and then all of the open HANDLEs and references must get released
But regardless, closing a console window does not even attempt to exit a console mode process that is attached to that console
Control+C usually triggers an exception in the process attached to the console, but that behaviour can be changed too
The way that you describe threads suggests to me that you haven’t considered how to signal them to exit in your code. And also that you are thinking about a single thread performing synchronous actions of a certain type. If nothing else, that’s a performance limiting design
But there is too much to say
Thank you, Mr. Tim and Mr. Bond. You said very useful things. Thank you.