When I saw through the various news outlets that Microsoft had released an out-of-band Firmware update for the Surface Pro 3, I knew it was probably worth jumping onto sooner rather than later. Little did I realize that tinkering with device drivers might cause some heartburn along the way. Whereas other users who hadn’t updated drivers beyond the Microsoft recommended items reported little or no difficulty with applying the firmware update, I found myself unable to do so for some time. The issue stems from one of the “unauthorized” drivers causing an issue upon shut down (which necessarily precedes restart) that prevented the system from achieving a normal and complete shutdown.
This issue is important because the handoff from the OS to the low level boot routines must succeed prior to shutdown, so that the firmware files (which are run after UEFI/BIOS comes up, but before the OS itself boots) can be handed over and scheduled to be run during the next restart. And, without a proper shut down, I found myself unable to achieve the restart that included loading and installing those new firmware updates. Eventually I was able to solve my problem by selecting only the Firmware Update for installation, after which the whole process went through without a hitch, and now the system is running more or less as it should be.
Some filenames here are more helpful than others, but no version info or dates anywhere.
This led me to understand that one ventures beyond the recommended device drivers for the Surface Pro 3 at one’s peril, and also showed me that MS is not doing a stellar job of documenting what the correct set of drivers should be. Instead they provide a pointer to a download page for Surface Drivers, where one can find a list of driver files for download that might (or might not) be relevant to one’s actual driver needs. Searching on the KB numbers in those filenames, where available, helps shed light on some things (such as the type of device for which a driver is included) but no light on others (especially aggravating: no information about version numbers or dates of the drivers included).
Next week, when I have a little more time, I’m going try to rectify that deficiency with a little old-fashioned detective work. In the meantime, I’m replacing drivers one at a time until I can find the one that makes my BSOD upon shut down problem go away once and for all. If anybody has more insight into this issue than I do, or can suggest a better troubleshooting approach, please post a comment here and let me know what’s up. Thanks, and have a great weekend!