RadeonResetBugFixService

Radeon Reset Bug fix service

Use case

You have configured pass-through of Radeon GPU into Windows Guest VM, intending to use it as the primary GPU, but whenever this VM reboots, the entire host system hangs and you have to power cycle the entire system, losing all data.

You have attempted solving this by various fixes found in the internet (startup/shutdown scripts in group policies, etc), but did not find them reliable. And even then, after applying these fixes, you find out that virtual GPU is now the primary display adapter, GPU acceleration is unavailable, and the screen connected to Radeon GPU is treated as the secondary screen.

This service intends to solve all the above problems. With it, you will be able to use Radeon GPU as your only GPU, with your actual display connected to Radeon as a primary display, and reboot your VM without triggering AMD reset bug - even installing Windows updates!

Limitations

Currently this project is only tested with Hyper-V VMs, and probably also supports KVM and QEMU, but it should be trivial to add other hypervisors support (the relevant files are Tasks\DisableVirtualVideoTask.cs and EnableVirtualVideoTask.cs).

Note that you will still have to add a virtual GPU to your VM, otherwise Windows won't boot.

Note that it will add 1-5 minutes both to startup and to shutdown time. So don't panic if your screen is black immediately after VM startup, it is expected.

Install instructions

Put RadeonResetBugFixService.exe in a permanent location.

In elevated command prompt in Guest VM, run

RadeonResetBugFixService.exe install

The screen may go blank several times during the process. It may take up to 15 minutes total (but should take less than 5).

Do not remove the file after that, or the service won't be able to start or stop. The install command does not create any copies, does not create a folder in Program Files, it simply adds a service to Windows, but the service refers to the exe file you invoked.

Upgrade instructions

In elevated command prompt in Guest VM, run

RadeonResetBugFixService.exe reinstall

The screen may go blank several times during the process. It may take up to 20 minutes total (but should take less than 5).

Uninstall instructions

In elevated command prompt in Guest VM, run

RadeonResetBugFixService.exe uninstall

The screen may go blank several times during the process. It may take up to 5 minutes total (but should take less than 2).

Debugging

The service stores its verbose log files in logs directory located next to the executable.

Frequent issues

Connecting to VM from the Host

This service disables Hyper-V video adapter, so you can no longer connect to VM using Basic sessions.

Enhanced sessions (which use RDP protocol) continue to work fine.

Unsuccessful reboots

This problem may rarely occur after updating Windows in Guest VM. It never happened for me during the ordinary usage.

If, after reboot, Guest VM for some reason did not recognize Radeon GPU (the screen connected to Radeon GPU remains inactive), or is unresponsive, DO NOT force-reboot Guest VM, or your Host system will hang up, and you will have to power cycle the entire system, losing all unsaved data.

Instead, gracefully reboot your Host (gracefully shutting down all guests).

If, after that, Guest VM will continue to behave oddly (using your actual display connected to Radeon GPU as the secondary one), just reboot the Guest VM gracefully.

Alternative (but more difficult) option: connect to VM from host, and restart the "Radeon reset bug fix" service. That way, you won't need to reboot the host; however, you have to be able to open graphic VM terminal sessions.

The cause of this problem:

Sometimes, while installing updates which require restart, Windows reboots not once but twice: first time from UI into "installing updates, step X of Y" screen, and second time from this screen back into UI.

For some reason, on that "installing updates" step, Windows starts all the services, but does not invoke pre-shutdown sequence, so the service ends up in an inconsistent state (because not everything could be done in shutdown sequence).

Force-rebooting Guest VM

If, for some reason, you find that you need to force reboot Guest VM (e.g. if you ran some program that made it unresponsive), DO NOT DO IT. This will prevent the service from shutting down GPU gracefully, and you will encounter the same old Radeon reset bug, which will force you to power cycle the entire host system.

Instead, if you are unable to make Guest VM response to your actions, reboot the host system gracefully.

You may need to gracefully reboot Guest VM again after that, similar to the previous example.

There is no simple way to shut down GPU gracefully when it is connected to the unresponsive Guest VM.

How it works

The extremely simplified description is as follows:

On service start (startup):

• Re-enable "basic video" system service automatic startup (so that in case of unexpected reboot, Windows will have at least one working (virtual) display adapter, otherwise Windows will not boot, and the only way to fix it is to boot into Recovery Console, and re-enable "basic video" system service automatic startup manually using regedit)

• Enable Radeon GPU

• Now that it's not the only GPU, disable virtual GPU

On service stop (pre-shutdown / shutdown):

• Stop Windows Audio service (otherwise it won't let us disable Radeon devices)

• Enable virtual GPU

• Now that it's not the only GPU, disable Radeon GPU

• Disable "basic video" system service automatic startup

Plus a bunch of magic to ensure that:

• After every graceful shutdown Radeon GPU is turned off whenever possible, so that Radeon reset bug won't occur on subsequent startup during the same host uptime session (again, whenever possible);

• At every startup, Windows has at least one enabled GPU driver/service (otherwise it won't get through the kernel boot sequence);

• At every attempt to disable a GPU, it is not the only available GPU (otherwise Windows won't let us disable it).