Driver makes Windows hang on boot

NTDEV
1

Hello,

I have a KMDF / NetAdapter based network driver, which works fine for many users, but a few (out of thousands/tens of thousands probably?) reported that system hangs on boot when the software, which uses the driver, is installed (see https://github.com/OpenVPN/ovpn-dco-win/issues/24 for details).

So my question is how this issue could be debugged further? I don’t have access to problematic machines and I am not sure I could ask users to get a second box and setup kernel debugging. I checked a boot log (ntbtlog.txt is attached to the ticket above) but could not spot anything interesting apart from “BOOTLOG_NOT_LOADED NetAdapterCx.SYS”. I am thinking about adding more DbgPrint() calls to DriverEntry and EVT_WDF_DRIVER_DEVICE_ADD. Could those logs somehow be obtained from the boot sequence? Any suggestions are welcomed.

2

Unreproducible is a problem. What you might be able to do is to convince
one of your problem users to set up keyboard crashdumps and have them try
to crash the system when it hangs and get you a crashdump to debug. See
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/forcing-a-system-crash-from-the-keyboard

However, this may or may not work depending on what part of the boot
process is hung.

Mark Roddy

3

Just a note that boot process does not completely hang. The small circle is spinning, under manufacturer (Acer) logo.

We got reports that this happens with particular model (two Acer Nitro AN515-54) and a few others - Dell XPS 15 9500, XPS 13 7390, XPS 13 9305, XPS 13 7390. However, another XPS 7390 works just fine.

I am thinking to go to shop and purchase Acer Nitro - they don’t have that exact model but let’s see if it can be reproduced on newer one. I wonder what Windows might be doing during boot? Does it try to start a driver, fail (by some reason?) and they retry infinitely? Is t possible to get more verbose log than “BOOTLOG_LOADED / BOOTLOG_NOT_LOADED <driver.sys>” ?

4

Answering own question.

The problematic code turned out to be WSK initialization in EvtDeviceAdd callback.

    LOG_INFO("Before calling WskCaptureProviderNPI()");
    // Capture the WSK Provider NPI. If WSK subsystem is not ready yet, wait until it becomes ready.
    GOTO_IF_NOT_NT_SUCCESS(done, status, WskCaptureProviderNPI(&driver->WskRegistration, WSK_INFINITE_WAIT, &driver->WskProviderNpi));
    LOG_INFO("After calling WskCaptureProviderNPI()");

While documentation indeed warns about using WSK_INFINITE_WAIT in DriverEntry:

To avoid adversely affecting the start of other drivers and services, a WSK application that calls WskCaptureProviderNPI from its DriverEntry function should not set the WaitTimeout parameter to WSK_INFINITE_WAIT or an excessive wait time. Also, if a WSK application starts very early in the system startup phase, it should wait for the WSK subsystem to become ready in a different worker thread than the one in which DriverEntry runs.

I believe it should be stated more clearly that WskCaptureProviderNPI must not be called with WSK_INFINITE_WAIT on EvtDeviceAdd. While it works on majority of systems, on some it leads to hard-to-debug boot issues.