How to debug / trace / log NVidia driver package install?

Hi.

Driver package 461.09 will not install, for me: right after checking compatibility of the system, it reports "Nvidia software was not installed" with the only option to close the installation window. The package is downloaded directly from NVidia.com, with OS and videocard correctly selected prior to download.

However, i am _able_ to install NVidia driver manually through the device manager, from that very same package's unpacked files, and it works as in enabling full resolution of the display (1920x1080) and other features display driver is responsible for! Of course, no PhysX, no NVidia control panel and no other parts of the package are installed that way, thus i still need to complete the package's installation process - which i can't, as per above. Please note that this problem persists over a year in my system, with many versions of driver packages. However, earlier, this problem did not exist - i was installing and using many earlier NVidia driver packages with no problem whatsoever for years before. And i did not add / change any hardware since the time NVidia installation worked fine. Nor did i reinstal / change my OS. I am very desperate to solve this issue by now.

I would very much like to learn how can i figure out specific cause of NVidia driver package installation failure. Is there any installation journal? Any error log? Any additional utility NVidia has available to debug / trace driver package installation process?

Thank you very much for any help!

P.S. Oh, and of course i tried all the usual suggestions: disabling antivirus software, closing all programs, i am always starting the setup as administrator and while logged in with administrator windows account, uninstalling all NVidia products prior to installation, etc. I.e. existing troubleshooting pages do not help in my case. I have also tried driver slimmer utility, twice (once being minimum possible install, just 3 components - core, driver, PhysX), and the utility works just fine - but install fails at exactly same point, after slimmed package's done checking system compatibility.

 

repair install windows, the setup exe via NVI2 scripting does stuff involving the systems RPC/COM handlers which are often broken (not going to say ddu is a factor, but its possible) in cases where the setup just throws failures.

pnputil / pnpapi installs don't query quite as much so have less points of failure.

 

How do i do this?

DDU was used by me to remove all things NVidia from the system, one of last times i tried to install 461.09 package, yes. It was used in normal mode and worked with no issues, as intended. No idea if i need to now fix something DDU could possibly break?

Note it's Windows 7 x64 SP1 system the problem is at, and pnputil syntax / features were much changed for/in Win10. Still, i will do my best to use pnputil when i get back to the system in question later today. Thanks!

 

https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

Perhaps this is a reason - https://nvidia.custhelp.com/app/answers/detail/a_id/5002/~/driver-installation-issues-on-windows-7

 

Will attempt debugview if pnputil won't help, and i'll post results here in any case.

And no, SHA-2 support is installed and functional, as verified by 3rd-party application which requires it (easyanticheat).

 

You can track file, registry, process and network activity with this
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

But the amount of information (in the log) is overwhelming.

 

Excellent tool indeed - fresh and yet still working even in Vista! No worries about log sizes, i'm quite creative with Ctrl-f in my notepad++. As with above, will use this one if nothing else helps and will report results later on (hopefully today) in any case. Thanks!

 

App shows trace in its own grid, and can save trace into file with its own format. So maybe Notepad++ is not the help here, but still this editor is really good.

PS I am sure filtering and searching are implemented in ProcMon...

PPS And according to description, no network trace. Maybe they discarded it or I mixed with some other app. Of course there is dedicated TCPView app in SysInternals suite.

 

On registry changes, http://www.nirsoft.net has some app that can be handy.

RegistryChangesView -is a tool for Windows that allows you to take a
snapshot of Windows Registry and later compare it with another Registry
snapshots, with the current Registry or with Registry files stored in a
shadow copy created by Windows.

RegFromApp -monitors the Registry changes made by the application that you
selected, and creates a standard RegEdit registration file (.reg) that
contains all the Registry changes made by the application

 

pnputil is no help, as it only allows to instal .inf packages - and PhysX part of the package, in particular, comes with none.

Debugview detected an error during the installation right away. Corresponding part of the log:

Spoiler: debugview log part

00001306 56.06090164 [7092] 58.241 | DEBUG: [ExtensionsLib.DevicesINFHandler] 37@CDevicesINFHandler:erformINFActionOnSupportedDevices : INFs found in package.
00001307 56.22848511 [7092] 58.409 | DEBUG: [DevicePackageUtil] 131@DevicePackageUtil::HardwarePresent : Found 1 candidate devices.
00001308 56.22856522 [7092] 58.409 | DEBUG: [ExtensionsLib.DevicesINFHandler] 46@CDevicesINFHandler:erformINFActionOnSupportedDevices : Supported devices found in package.
00001309 86.39826202 [7092] 88.579 | ERROR: [NVI2.InstallThread] 54@CInstallThread::ThreadProc : Install failed - Exception {0x800705b4 - Возврат из операции произошел из-за превышения времени ожидания.; File: InstallationStepper.cpp; Line: 769; Extension failed during call toAnalyze} - going to fail state.

Googling "0x800705b4", i see a recommendation to DDU the system. Which i already did to no success. So far it's still a deadend, overall, as this error tells me nothing about why NVidia installation process gets halted for 30 seconds and then fails to timeout.

Will keep digging, but if the above rings any bells - please advice...

 

You have a timed out installation operation. But why - only NV guys could tell...

 

Get log files - https://nvidia.custhelp.com/app/answers/detail/a_id/3171/~/how-to-enable-nvidia-graphics-driver-and-geforce-experience-installer-logging
and send the files to support - https://nvidia.custhelp.com/app/ask

Not sure if that's helpful, but you can try to skip "Analyze" call which causes the exception.
Open 461.09-desktop-win7-64bit-international-whql\NVI2\NVI2.dll in Hex-editor and replace the following bytes:
E8 51 C2 FF FF 83 78 18 06 0F 8C 95 00 00 00 → E8 51 C2 FF FF 83 78 18 7F 0F 8C 95 00 00 00

 

Based on the exception location, its definitely system RPC/COM corruption.

run the windows update readiness tool to repair the install

This will just result in the install failing later in the process.
Need to fix the system's corrupted RPC/WMI data.

 

Gentlemen, i kindly thank you all for all your help, but the matter is now closed in most unsatisfactory way.

In my desperation, among other things i allowed installation of all the "important" Windows updates, which i never did for over five years this Win7 installation was functioning (rather well) on the machine. One of recently published updates, then, completely broke the OS by adding (without any notice / warning) some changes to boot loader. Windows recovery failed to fix it, and after several changes completely broke itself, too - going to auto reboot the machine before even loading itself completely. Thing is, there is a number of HDDs in the system, boot loader is on one of them, while the system itself was installed on a different RAID 0 massive (Intel controller) - and apparently this kind of setup is what Microsoft failed to deem possible in that recent OS update of theirs.

Worse yet, i don't know how they did it, but reinstalling from very same distributive of Win7 into that very same RAID 0 massive, using native motherboard's manufacturer (MSI) RAID driver - is now impossible. Did MS manage to flash something into BIOS with those OS updates to screw it up? Or more likely, did it screw up RAID disk itself in some wicked way (which i can't just empty up and re-make from scratch at the time as it has lots of valuable data in it)? However it'd be, i was forced to change from RAID to IDE mode for HDDs to reinstall the OS (which, of course, means no more double speed from RAID and no data redundancy).

But guess what, after i got that same Win7 up and running, some essential (like SHA-2) OS updates and SP1 added - the NVidia package (slimmed) installed no problem. Proving there was nothing wrong with the hardware, nothing wrong with OS distributive, no actual need to install all those "important" updates to solve the matter - and nothing wrong with the ways i was attempting the install.

Bastards in Redmont messed up big-time, again - that's the only conclusion i can make here. Sadly it'll remain unknown what exactly was preventing NVidia package install in the above case, as that OS installation is now dead (i sure tried few tricks to reanimate it, to no avail). Let this sad story be yet one more to many similar cases when installing all MS updates (even if only "important" ones) into some quite non-standard rig - may at times result in a complete catastrophe.

 

Sounds like you had the early sha256 update installed that was missing the boot manager files, so the subsequent enforcement of sha256 in one of those patches you hadn't installed yet caused you a problem.

if you already had the sha256 patch installed there was a necessary order to follow to retain a bootable install that involved installing a specific bitlocker update.

When this update is installed, an issue when arises for Asus UEFI mainboards set for WHQL boot (turn it off)

No.

 

1st, it's MSI MB, not Asus. 2nd, files missing in an update, enforcement of system-killing routine, and making bitlocker update required in a system which never used bitlocker - are exactly things of the "Redmont messed up big-time, again" sort, in my book. And i would not be surprised at all if the mess is, in fact, intended, knowing plenty rather dirty things MS did to push customers away from pre-W10 systems. 3rd, in absolutely any case, failure to roll back to previous functional state - is unforgivable no matter the issue.