Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
I'm looking for some direction on where to start diagnosing this issue. I built a file system mini filter based on the Windows scanner example. I am getting a freeze on Windows logon only on some systems. On many other systems the user service and driver code works just fine. It seems to reliably freeze on the "bad" systems and reliably work on the good systems. On the systems that freeze I identified through user service debug messages that that the call to FilterConnectCommunicationPort never returns. This call occurs early on in the service startup. I believe that API call should be invoking my port connect routine in the driver. I pasted that below.
For reference, I'm an experienced C++ Windows API developer but this is my first foray into production filesytem minifilters. I've been developing this product over a year. Any debugging tips on minifilters here would be welcomed. As well as simple "did forget to" responses. I'm looking for any general inclinations on what to look for or what this could be. Thank you.
NTSTATUS ZTEPortConnect( PFLT_PORT ClientPort, PVOID ServerPortCookie, PVOID ConnectionContext, ULONG SizeOfContext, PVOID* ConnectionCookie ) { PAGED_CODE(); UNREFERENCED_PARAMETER(ServerPortCookie); UNREFERENCED_PARAMETER(ConnectionContext); UNREFERENCED_PARAMETER(SizeOfContext); UNREFERENCED_PARAMETER(ConnectionCookie = NULL); FLT_ASSERT(ZTEData.ClientPort == NULL); FLT_ASSERT(ZTEData.UserProcess == NULL); PT_DBG_PRINT(PTDBG_TRACE_ROUTINES, ("ZTEDriver!ZTEPortConnect: Entered\n")); ZTEData.UserProcess = PsGetCurrentProcess(); ZTEData.ClientPort = ClientPort; PT_DBG_PRINT(PTDBG_TRACE_CONNECTION, ("ZTEDriver!ZTEDriverPostOperation: connected, port=0x%p\n", ClientPort)); PT_DBG_PRINT(PTDBG_TRACE_ROUTINES, ("ZTEDriver!ZTEPortConnect: Exit\n")); return STATUS_SUCCESS; }
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 30 January 2023 | Live, Online |
Developing Minifilters | 20 March 2023 | Live, Online |
Internals & Software Drivers | 17 April 2023 | Live, Online |
Writing WDF Drivers | 22 May 2023 | Live, Online |
Comments
Are you able to connect WinDbg to the bad systems? You can then use the
!stacks
or!process
command to find the thread with the hungFilterConnectCommunicationPort
. The stack for that thread should give you clues on what is causing the hang. If you cannot connect WinDbg, then configure a manual dump (https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/forcing-a-system-crash-from-the-keyboard) so that you can generate a dump file for the hang and analyze the dump on a machine with WinDbg. Make sure to download the appropriate symbols for the Windows modules (e.g. fltmgr.sys, nt) so that WinDbg can correctly resolve the functions in the stack.