Radeon Reset Bug fix service
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
RadeonResetBugFix/README.md

179 lines
6.0 KiB

5 years ago
# RadeonResetBugFixService
Radeon Reset Bug fix service
4 years ago
## 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,
4 years ago
GPU acceleration is unavailable,
and the screen connected to Radeon GPU is treated as the secondary screen.
4 years ago
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!
4 years ago
## Limitations
Currently this project is only tested with Hyper-V VMs,
and probably also supports KVM and QEMU,
4 years ago
but it should be trivial to add other hypervisors support
(the relevant files are `Tasks\DisableVirtualVideoTask.cs` and `EnableVirtualVideoTask.cs`).
4 years ago
**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.
4 years ago
## Install instructions
4 years ago
Put `RadeonResetBugFixService.exe` in a permanent location.
4 years ago
In elevated command prompt in Guest VM, run
```
RadeonResetBugFixService.exe install
```
4 years ago
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).
4 years ago
## Uninstall instructions
In elevated command prompt in Guest VM, run
```
RadeonResetBugFixService.exe uninstall
```
4 years ago
The screen may go blank several times during the process.
It may take up to 5 minutes total (but should take less than 2).
4 years ago
## 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
4 years ago
On service stop (pre-shutdown / shutdown):
* Stop Windows Audio service
(otherwise it won't let us disable Radeon devices)
* Enable virtual GPU
4 years ago
* 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).