Windows PV Drivers - I have one Win 11 VM with a problem

mlcrane

Hi,

In the middle of an "all hands" P2V project, so far everything has been working just fine - P2V a machine, boot it under XCP-ng, install the Win PV drivers, reboot. All good.

But one machine I did over the weekend is flat out refusing to install any Win PV drivers whatsoever - "XCP-ng 8.2.2.200", "XCP-ng 9.0.9136.44" or even "XenServer Guest Tools" latest version downloaded a couple hours ago to test.

"XCP-ng 9.0.9136.44" installs for a while, gets to what I must assume is the drivers (the dialog lists XenBus etc.), then it starts rolling back. Final dialog just tells me it "ended prematurely".

"XCP-ng 8.2.2.200" and "XenServer Guest Tools" do similar, but at least they are giving me "an error" of sorts. Install progresses until it attempts to install the "Installation and Update Agent" service, said service refuses to start ("5: access is denied" if I go into Services and try manually starting it, regardless of user I tell the service to use, up to and including the Domain Administrator account) and then I am left with no choice but to cancel/rollback. Same "InstallAgent" fails to start under XenServer Guset Tools, they just name it slightly differently.

I have the physical machine nearby, so I tried doing the same on the actual hardware that made the VM, and it's doing exactly the same thing, so clearly, whatever is wrong is "buried deep within the Windows install". Doesn't what user account I use for the install, it always behaves the same way.

Anyone have any suggestions on things I can do to get the drivers installed at the very least? Win 11 performs "dire" without them.

mlcrane

Oh, and in hopes of "covering bases" - Yes, I've run XenClean, multiple times, no difference.

mlcrane

Ooh flippin' heck. So, I've had the VM "logged in" since midday (UK) just doing nothing at all (in hopes...). I tried the install (8.2.2) again, same result as every other time, EXCEPT...

This time, after closing the installer, a new dialog popped up telling me about the install.log.

I don't really see anything "new" in the log (same 1920 error on the service start), so I'm just going to blank it, run the install again to failure, then grab it for here (diagnosis).

Install.log.txt

dinhngtu

@mlcrane Could you try reinstalling the 9.0.9137 tools with the following troubleshooting intructions:

For installing:
msiexec.exe /i XenDrivers-x64.msi /log install.log

For uninstalling:
msiexec.exe /x XenDrivers-x64.msi /log uninstall.log

Please include this log along with the file C:\Windows\INF\setupapi.dev.log in your bug report. These files will help us troubleshoot any installation issues.

john.c

@mlcrane said in Windows PV Drivers - I have one Win 11 VM with a problem:

Ooh flippin' heck. So, I've had the VM "logged in" since midday (UK) just doing nothing at all (in hopes...). I tried the install (8.2.2) again, same result as every other time, EXCEPT...

This time, after closing the installer, a new dialog popped up telling me about the install.log.

I don't really see anything "new" in the log (same 1920 error on the service start), so I'm just going to blank it, run the install again to failure, then grab it for here (diagnosis).

Install.log.txt

If you haven’t blanked the VM yet, can you check its Event Log - the main Windows logging system? There may be more details about the service that failed to start.

mlcrane

@john.c Did that, so many times. The event log tells me nothing that the installer isn't. And it's the same as when attempting to start the service in either services or on the Command Line.

Oh, and for clarity, "blank it" was referring to the install log not the VM (or more specifically I guess, the VHD), which I did and the log is attached under that line in the post. The VHD's being kept whether this gets resolved or not. At worst, I'm going to offer the user whose machine this is a brand new install of Win 11 tomorrow, which I know full well will fix this particular issue, and he can have the "old C:" attached temporarily to copy over anything he needs to copy over.

mlcrane

@dinhngtu said in Windows PV Drivers - I have one Win 11 VM with a problem:

@mlcrane Could you try reinstalling the 9.0.9137 tools with the following troubleshooting intructions:
For installing:
msiexec.exe /i XenDrivers-x64.msi /log install.log

For uninstalling:
msiexec.exe /x XenDrivers-x64.msi /log uninstall.log
Please include this log along with the file C:\Windows\INF\setupapi.dev.log in your bug report. These files will help us troubleshoot any installation issues.

Well, bother (because)... That "just worked". No errors, no failures, no rollbacks. 9.0.9137 (using the command you provided) appears to have installed.

I'm including the requested log files, since more knowledgeable folks might see something, but I now need to restart the VM and check everything is correctly "detected" on the other side. Assuming "yes", many, many thanks; I can let the user have "their machine" back in the morning.

setupapi.dev.log.txt
install.log.txt

mlcrane

@mlcrane said in Windows PV Drivers - I have one Win 11 VM with a problem:

... everything is correctly "detected" on the other side. Assuming "yes", many, many thanks; I can let the user have "their machine" back in the morning.

Bloody, bloody Microsoft ruining everything they touch. Yup, that's all working following a reboot. Again, @dinhngtu a thousand, million thanks. I was at my wits end on this and as mentioned to @john.c, I was getting ready to give this user a fresh install of Win 11.

Management Agent is a little upsetting, but I took the screenshot straight after the VM booted, so it may be that logging in/waiting a bit after that will get the Agent correctly detected. At the end of the day and in the short term, the Agent is less important to me than the I/O drivers.

dinhngtu

@mlcrane You're welcome! If everything started correctly, you should see this in Xen Orchestra along with VM IP:

The previous error you had "Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider" didn't quite make sense to me since the driver package was signed by Microsoft, perhaps you were missing an important update at the time, or your VM clock was out of sync?