Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017

Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 5  
20 Apr 17 16:24
ashish kohli
Join Date: 29 Nov 2014
Posts To This List: 29
ndis lwf driver binding removed during windows upgrade

Hi experts We are facing a peculiar problem. With UEFI BIOS and secure boot enabled During Windows 10 upgrade to 1607 version our ndis lwf driver bindings are getting removed. --> what could be possible cause? --> during upgrade the machine restarts multiple times,how can I debug the issue. --> The current upgrade logs are of no help.Any idea which logs to enable in this case. Any type of help is highly appreciable.
  Message 2 of 5  
20 Apr 17 16:28
ashish kohli
Join Date: 29 Nov 2014
Posts To This List: 29
ndis lwf driver binding removed during windows upgrade

The problem is only reproduced if UEFI Bios and secure boot enabled. I am not able to understand the relation of ndis lwf bindings and secure boot. In any case the ndis lwf driver is WHQL signed. Even a reinstall after upgrade works. But removal of bindings during upgrade we are not able to find root cause.
  Message 3 of 5  
21 Apr 17 16:36
Jeffrey Tippet [MSFT]
Join Date: 29 Mar 2010
Posts To This List: 407
ndis lwf driver binding removed during windows upgrade

I own the code that migrates NDIS LWF drivers during a Windows Upgrade. I = am pretty darn sure that there's nothing in that code that looks at Secure = Boot state. So I don't have an exact solution for you. What I can instead= offer is a bit of background on how this is supposed to work (so you'll be= better-equipped to notice anything unusual) and tell you where the good lo= g files are. When it comes to LWFs, Windows has 2 separate databases. PNP owns the phys= ical driver package (the INF and .SYS file); while netcfg owns the logical = registration of your driver with the network stack. So there's two migrati= ons that have to happen, and two places to check for log files.=20 First, PNP migrates all driver packages. You can check whether PNP even kn= ows about your driver package anymore, after the OS upgrade. Compare the o= utput of "pnputil.exe -e" before & after the upgrade, and see if your drive= r package is getting discarded by PNP's driver store. You can also check PNP's log files for mention of your driver; they're usua= lly pretty good about logging any problems. Grep c:\windows\inf\setupapi.*= .log for your INF, zeroing in on events by timestamp. You should see some = chatter about migrating your driver package. If pnputil.exe -e knows about your driver package, then maybe netcfg couldn= 't migrate it. For each LWF driver on the downlevel OS, netcfg calls INetC= fgClassSetup::Install again once the system boots into the uplevel OS. Netcfg writes out C:\windows\system32\netsetupmig.log while it's doing that= migration. You should see lines like: 02:57:38: Migrating your_driver_name. 02:57:38: Attempting to re-install your_driver_name via its INF 02:57:38: Merging your_driver_name. . . . 02:57:40: Committing the NetSetup transaction. 02:57:40: Migration succeeded.
  Message 4 of 5  
24 Apr 17 16:30
Alan Adams
Join Date: 20 Dec 2010
Posts To This List: 19
ndis lwf driver binding removed during windows upgrade

Jeffrey Tippet <> wrote: > Netcfg writes out C:\windows\system32\netsetupmig.log while it's doing that migration. Thanks for the useful information, Jeffrey Tippet. We're facing a similar case where upgrade from Windows 10 1607 (RS1) or earlier to Windows 10 1703 (RS2) results in the removal of our NetClient-class component "in some cases" and "for reasons unknown". Similar to what akohli_2004 reported, we see "machines that upgrade fine, but others don't." It's not specifically Secure Boot in our case, though. But for example, our testing was showing a different outcome on domain-joined machines versus non-domain-joined. But our customers have also reported "nothing is lost" in the same configurations where we see 100% failure rate in testing inside our lab, so there is certainly some unidentified variable in the outcome. Note we do experience this as "new to Windows 10 1703." We do not face any similar problems upgrading one Windows 10 build to the next when going between 1507, 1511 or 1607 (TH1, TH2, RS1). The problem also didn't happen in build 15058 or earlier of the RS2 insider preview builds, and first occurred in the 1506x March builds. The setupapi logs we've reviewed have never suggested any kind of failure in what SETUPAPI was attempting to do with our driver. The netsetupmig.log in one of our failure scenarios shows a progression like I've included at the end of this post. The log shows we're seeing ERROR_MOD_NOT_FOUND (0x8007007E) during the first "Attempting to re-install NV_NVCLIENT via its INF", followed by ERROR_TIMEOUT (0x800705B4) on the next attempt, followed by 0x800106D9 (presumably RPC failure of some kind?) on the next attempt, followed by two occurrences of ERROR_SERVICE_MARKED_FOR_DELETE (0x80070430) on the final attempts. ERROR_SERVICE_MARKED_FOR_DELETE fits with one of the "variable outcomes" we seem to experience. When the 1703 upgrade is "finished" in that it allows the user to logon to Windows for the first time, when things are "broken" we find our drivers all still marked SERVICE_DISABLED (0x4) as the start type. But then once you finally decide to reboot the 1703 machine and logon for a second time, now our drivers are simply /gone/ from CurrentControlSet. So a pending delete definitely seemed to be in play. But it's as though this decision wasn't made until /after/ the upgrade was "finished" and we were allowed to logon. (Since the deletion didn't actually occur until the second reboot after completion of the upgrade.) Does the initial processing shown in the NETSETUP log happen at a time when I should be successful in running Process Monitor or similar to capture a broad view of what is being attempted when NETSETUP encounters the original ERROR_MOD_NOT_FOUND condition? Or is it happening at a time when upgrade will have disabled most things and rebooted into the controlled upgrade environment. Or maybe just some further granularity / verbosity to the NETSETUP log I can enable, that might reveal more info. > 12:10:57: Getting Client Drivers > 12:10:57: Adding NV_NVCLIENT > 12:10:57: Adding ms_msclient > 12:10:57: Getting Binding Paths > 12:10:57: Writing graph to uplevel. > 12:10:57: Creating a NetSetup Transaction for migration with environment type 9. > ... > 12:10:57: Migrating non-PnP enumerated objects. > 12:10:58: Migrating NV_NVCLIENT. > 12:10:58: Not migrating ms_msclient. <...excess quoted lines suppressed...> Note we're also seeing a bunch of entries like the following between each install attempt, but suspect they're just secondary to the install failure that occurs first. Omitted the repeats just for brevity: > 12:10:59: Migrating bind path {2788AD3C-187C-4850-A5D0-CD31109B725D},ms_tcpip,NV_NVCLIENT > 12:10:59: The binding path {2788AD3C-187C-4850-A5D0-CD31109B725D},ms_tcpip,NV_NVCLIENT did not correspond to a binding path in NetSetup. Not migrating. > 12:10:59: Successfully migrated bind path. Alan Adams Client for Open Enterprise Server Micro Focus
  Message 5 of 5  
24 Apr 17 18:04
Jeffrey Tippet [MSFT]
Join Date: 29 Mar 2010
Posts To This List: 407
ndis lwf driver binding removed during windows upgrade

Hmm, that's a rough log file. We do keep a slightly more detailed log in c= :\windows\logs\netsetup\service*.etl . If you send me a direct mail with t= hose attached, I'll take a look. The ERROR_MOD_NOT_FOUND is probably coming from an attempt to run the notif= y object from your driver package. Does that driver have a notify object d= ll? My guess is that your driver package is not where the OS migration eng= ine expected to find it. I'm surprised that that error apparently eventual= ly resolves itself. I diffed the migration code in our source control system, and very little c= hanged between 1607 and 1703, so I don't know offhand what could explain th= e different results you're seeing. You're right that the warnings about missing bindings are just a cascading = issue from not being able to reinstall the driver.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 12:04.

Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license