I’ve chased down a strange sequence of clues over the past few days to finally resolve an odd device driver issue. The reason I say the device driver issue is odd stems from its origin. It followed in the wake of a recent Security Update for the Adobe Flash Player. “I don’t see that a device was involved,” was my reaction to unwinding the clues that led me to this discovery. I’m sure other readers may react likewise. But the clues that led me to this understanding are convincing. Thus, let me present the evidence for fixing Win10 restart PC to finish installing drivers issue.
Evidence for Fixing Win10 Restart PC to Finish Installing Drivers Issue
On June 8, I got a notification from Windows 10 that I needed to finish installing a device driver. With no new device drivers added to my machine that day, I was a little puzzled. First off, I turned to Reliability Monitor, which showed me only two information items, neither of which specifically mentioned a device driver:
Only two info items for that day, neither of which is labeled explicitly as a device driver. Curious, eh?
[Click image for full-sized view].
Quite naturally, this led me to the Windows log file setupapi.dev.log, where Windows 10 logs all device driver additions and changes. For the record, this file resides in %windir%\INF, and can be an occasional and valuable source for driver insight. This time, it showed me an entry at the same time the Adobe Flash Player update was installed. Thus, the evidence is unshakeable that part of the security update includes a device driver of some sort or another. Here’s that log entry:
1 [Boot Session: 2018/06/08 10:41:05.428]>>> [Finish Install Action – USB\VID_046D&PID_C52B&MI_02\6&44B3556&0&0002]
2 >>> Section start 2018/06/10 08:42:21.371
3 dvi: {Build Driver List} 08:42:21.375
4 dvi: Searching for hardware ID(s):
5 dvi: usb\vid_046d&pid_c52b&rev_2406&mi_02
6 dvi: usb\vid_046d&pid_c52b&mi_02
7 dvi: Searching for compatible ID(s):
8 dvi: usb\class_03&subclass_00&prot_00
9 dvi: usb\class_03&subclass_00
10 dvi: usb\class_03
11 dvi: {Build Driver List – exit(0x00000000)} 08:42:21.385
12 dvi: Class GUID of device changed to: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}.
13 dvi: {DIF_FINISHINSTALL_ACTION} 08:42:21.385
14 dvi: Using exported function ‘CoDeviceInstall’ in module ‘C:\WINDOWS\system32\LkmdfCoInst.dll’.
15 dvi: CoInstaller 1 == LkmdfCoInst.dll,CoDeviceInstall
16 dvi: CoInstaller 1: Enter 08:42:21.392
17 dvi: CoInstaller 1: Exit
18 dvi: Default installer: Enter 08:42:21.393
19 dvi: Default installer: Exit
20 dvi: {DIF_FINISHINSTALL_ACTION – exit(0xe000020e)} 08:42:21.393
21 <<< Section end 2018/06/10 08:42:21.394
22 <<< [Exit status: SUCCESS]
Digging Into Details
A search on the device ID involved, however — namely usb\vid_046d&pid_c52b&rev_2406&mi_02 (line 5) — tells me it’s actually a Logitec device driver. Most likely, it’s for the Universal USB Receiver that connects to my RF-based M325 mouse. So actually, Flash Player isn’t responsible. It’s something that came along for the ride with the Flash player. In fact, the issue is that even after restarting the machine in the wake of the update, the install status of the driver fails to clear. The “Configure a device” troubleshooter keeps displaying the same status, no matter how many times I restart my PC. Here’s what that looks like:
The desired transformation failed to occur, despite numerous restarts. Sigh.
[Click image for full-sized view.]
Some quick research on Bing led me to some possible fixes. The first one I tried indicated that an anti-malware package could interfere with the proper status reset during the restart process. So I disabled Norton on my PC for 15 minutes, restarted the machine, and presto! Problem solved. It just goes to show that you can indeed figure out how to fix many Windows gotchas, if you carefully collect the evidence available and let it lead you to a solution online. Case closed, thank goodness!
