**UPDATE** to the **UPDATE**  **UPDATE**
There has been “multiple TONS” of amazing and diligent work done by some extremely talented individuals to not only uncover some extreme deficiencies in the MS update process but more importantly, to help the community to cope, resolve and move forward! If this blog post is along the lines of anything you are experiencing, please immediately take a moment to read through this blog post by my friend @AdamGrossTX which should answer all your questions and also provide a solution for “what ails you”. Please also take a moment to follow another friend, @SeguraOSD who has developed a super slick solution for servicing your windows images which can be found HERE. As if I need to say it, get to following the dynamic duo of @miketerrill and @gwblok as well as they have been key in the discovery, testing and resolution of this matter as well!!
**UPDATE**Â Â Â **UPDATE**
My good friend Mike Terrill  (@miketerrill) discovered that the devinv.dll version that was previously our Savior (10.0.17060.1029) has flipped sides with the newest June servicing of 1709 and has taken the form of the DEVInv.dlL! Mike has reported seeing the same behavior as described about devinv.dll (10.0.16299.xxx) in my blog below, but this time with devinv.dll (10.0.17060.1029)!!! OK OK OK . . . that is a lot of numbers so lets just add a simple way to look at it. If you are upgrading to 1709 using a .wim with:
Win10 1709 Pre-June Servicing  – you need to have devinv.dll 10.0.17060.1029 *download available below
Win10 1709 Post-June Servicing – you need to have devinv.dll 10.0.17060.1030 *download available below
Failure to comply with these versions could find you with a load of hung IPUs!!
Original Post:
I recently ran into a challenge while working at a client’s site where my Windows 7 to Windows 10 1709 In-Place Upgrade (IPU) would effectively stall out shortly after setup.exe was initiated by the Task Sequence (TS). I banged my head on this for 24 hours before I finally found what appears to be the root cause of the challenge and ultimately, the resolution!
Getting right to the point, in looking at my setupact.log while it was in $WINDOWS~BT\Sources\Panther I saw that it had halted amongst a sea of RED errors referencing DeviceInventory and the device map.
Info CSI 00000002 Shim considered [l:250{125}]”\??\C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.23505_none_681aa442f6fed7f0\pkgmgr.exe” : got STATUS_SUCCESS
Error CONX Windows::Compat::Appraiser::DriverInventory::MakeAndAppendAssetFromInf (333): Error getting driver info: [0xe0000100].[gle=0xe0000100]
Error CONX Windows::Compat::Appraiser::DriverInventory::FindAndAppendDriversFromFolder (264): Error creating asset from C:\$WINDOWS.~BT\Drivers\User\Input\HVG218WW\Autorun.inf: [0xe0000100].[gle=0xe0000100]
Error CONX Windows::Compat::Appraiser::DriverInventory::FindAndAppendDriversFromFolder (249): Error appending in subdirectory C:\$WINDOWS.~BT\Drivers\User\Input\HVG218WW: [0xe0000100].[gle=0xe0000100]
Error CONX Windows::Compat::Appraiser::DriverInventory::FindAndAppendDriversFromFolder (249): Error appending in subdirectory C:\$WINDOWS.~BT\Drivers\User\Input: [0xe0000100].[gle=0xe0000100]
Error CONX Windows::Compat::Appraiser::DriverInventory::FindAndAppendDriversFromFolder (249): Error appending in subdirectory C:\$WINDOWS.~BT\Drivers\User: [0xe0000100].[gle=0xe0000100]
Error CONX Windows::Compat::Appraiser::DriverInventory::GetInventory (167): Error finding and appending drivers: [0xe0000100].[gle=0xe0000100]
Info CONX Windows::Compat::Appraiser::DriverInventory::GetInventory (179): Finished Driver Inventory.
Error CONX 0x80070102 Failed to generate device map
Error CONX 0x80070102 GetDeviceMap failed
Error CONX 0x80070102 CDevInventory::CreateDevInventoryToCache failed
Error CONX Windows::Compat::Appraiser::WicaDeviceInventory::RunDeviceInventory (446): Failed to get device inventory from devinv: [0x80070102].[gle=0x80070102]
Error CONX Windows::Compat::Appraiser::WicaDeviceInventory::GetInventory (352): Device inventory failed setup devices run, trying other runs: [0x80070102].[gle=0x80070102]
Info CONX Windows::Compat::Appraiser::WicaDeviceInventory::GetInventory (368): DevInv version is 10.0.16299
Info CONX Windows::Compat::Appraiser::WicaDeviceInventory::GetInventory (369): Processing Device Inventory File.
Error CONX Windows::Compat::Appraiser::WicaDeviceInventory::GetInventory (378): AtLeastOne table validation failed, trying other runs: [0x8007000d].[gle=0x8007000d]
Info CONX Windows::Compat::Appraiser::WicaDeviceInventory::GetInventory (409): Finished reading Device Inventory. 0 Devices
As you can see from the final lines of the log before setup halted, there are multiple errors such as 0x80070102 Failed to generate device map and Failed to get device inventory from devinv: [0x80070102].[gle=0x80070102]. The second error was the proverbial fork in the road, specifically where it references devinv. Devinv is devinv.dll, which is critical to the processing of the Device Inventory Library during setup.
Again looking back at the setupact.log above, a few lines down from the aforementioned errors I got my second clue: DevInv version is 10.0.16299.xxx This is the devinv.dll version that ships in 1709 and from what I could tell, exists in all of the available 1709 downloads on MSDN. Focusing on this version of devinv.dll, I scoured the web for any insight and ran across a forum string where a gentleman had noticed that there was a discrepancy between the version of the devinv.dll in the setups that failed (10.0.16299.xxx) and the version that existed in a IPU that completed successfully (10.0.17060.1029).
This is when all the magical fireworks went off!! I downloaded and searched through a couple of newer 1709 ISOs, only to find the same 10.0.16299 version. I then decide to take a look at my personal laptop running Win10 1709 and nestled down in C:\Windows\System32 i found it . . . devinv.dll 10.0.17060.1029!!
I quickly copied this over to my client’s site, swapped it with the existing devinv.dll in the sources directory of my Operating System Upgrade Package and updated my DP’s. On the very next attempt I made to run an IPU on a machine that had never worked . . . it flew right through the setup and rewarded me with a successful Win10 1709 upgrade!!
QUICK RESOLUTION STEPS **UPDATED**
- Verify you have the same challenge (reference the screenshot of the setupact.log above)
- Determine if your .wim has the June servicing applied
- Locate a devinv.dll file that is version 10.0.1760 (I am providing one here to download ==> devinv
- June Servicing Applied: You will need to have devinv.dll 10.0.17060.1030 (Download this devinv.dll) *thank you @AdamGrossTX
- June Servicing NOT Applied: You will need to have devinv.dll 10.0.17060.1029 (Download this devinv.dll)
- Replace the existing devinv.dll in the sources directory of your Windows 10 1709Â Operating System Upgrade Package
- Update your DP’s
- Grab a drink, prop your feet up and watch the beautiful flowing setupact.log!!!
I hope this ends up saving some of you a lot of time and frustration and let me know if you have any challenges!
~m
c’est un superbe blog
Merci beaucoup!
If you do this workaround, you should still open a support case with Microsoft so they track/fix the underlying problem.
I am totally not against that and as soon as the waters settle here and I am not doing 14+ hours days . . . I will be making that submission. 😉
[…] UPDATE 5/21/2018 – I just found a possible alternative root cause and workaround. I’m going to test and update if needed. https://twitter.com/jarwidmark/status/998591545392685057 and https://blog.ctglobalservices.com/configuration-manager-sccm/mag/devicemap-and-device-inventory-failu… […]
Thanks, that was very helpful!
[…] Marc Graham – https://blog.ctglobalservices.com/configuration-manager-sccm/mag/devicemap-and-device-inventory-failu… David Segura – https://www.osdeploy.com/osbuilder/overview Gary Blok – […]