search

4d61726b / VirtualKD-Redux

VirtualKD-Redux - A revival and modernization of VirtualKD
GNU Lesser General Public License v2.1
812 stars 136 forks source link

Virtual box doesn't boot windows 11 when i load with "Disable Driver Signature Enforcement" option #56

Closed parchinskiy closed 10 months ago

parchinskiy commented 10 months ago

Describe the bug Hello, can you help me? I'm trying to activate debugging according to the instructions https://github.com/4d61726b/VirtualKD-Redux/blob/master/VirtualKD-Redux/Docs/Tutorial.md When I do step 4 from section Guest VM virtual box freezes. If I wait 5-10 minutes, the automatic recovery windows appear.

To Reproduce Steps to reproduce the behavior: 1)Run vminstall.exe from target64 folder on guest os 2)Select options "Replace kdcom.dll" 3)Restart Guest 4)Select "Disable Driver Signature Enforcement" and boot 5)Gues OS doesn't boot

Expected behavior OS boots successfully

Screenshots State in which loading stops image

Configuration (please complete the following information):

4d61726b commented 10 months ago

You seem to be missing a few steps.

On your host, did you:

  1. Add the certificate
  2. Use VirtualBox7_Integration.exe to enable debugging for that specific VM
  3. Run vmmon64.exe

https://github.com/4d61726b/VirtualKD-Redux/blob/master/VirtualKD-Redux/Docs/Tutorial.md#host-virtualbox-only https://github.com/4d61726b/VirtualKD-Redux/blob/master/VirtualKD-Redux/Docs/Tutorial.md#host-final-steps

parchinskiy commented 10 months ago

You seem to be missing a few steps.

On your host, did you:

  1. Add the certificate
  2. Use VirtualBox7_Integration.exe to enable debugging for that specific VM
  3. Run vmmon64.exe

https://github.com/4d61726b/VirtualKD-Redux/blob/master/VirtualKD-Redux/Docs/Tutorial.md#host-virtualbox-only >https://github.com/4d61726b/VirtualKD-Redux/blob/master/VirtualKD-Redux/Docs/Tutorial.md#host-final-steps

I think I did it. I tried it with Windows 10 and it worked. I'll try again with Windows 11 and post the results

4d61726b commented 10 months ago

I'm assuming this was addressed with my last suggestion so I'm closing it for now

0xbadb0d00 commented 10 months ago

I have the same problem. Did you solved it @parchinskiy?

I followed all instructions in the tutorial for a Virtual Box instance, but when I select the option to disable driver signing enforcement, the system freeze exactly like in the screenshot showed in the first post.

Can you please @4d61726b help us?

0xbadb0d00 commented 10 months ago

The OS version that I installed on the guest is the same of the author post, and the VirtualBox version and VirtualKD too.

This is the guest OS in stuck:

error

I want to add also another information: If for example I select the another option in the boot option, like "Debugging mode" instead of "Disable Driver Signature Enforcement", the OS opening well, but without debugging kernel feature enabled

4d61726b commented 10 months ago

It works fine me for me. Can you:

  1. Close every window on your host. Restarting your host would be the easiest way to ensure of this.
  2. RunVirtualBox7_Integration.exe. Ensure that the correct VM is set to Enabled
  3. Run vmmon64.exe
  4. Use VirtualBox7_Integration.exe to launch VirtualBox
  5. Launch the virtual machine from VirtualBox
0xbadb0d00 commented 10 months ago

It works fine me for me. Can you:

1. Close every window on your host. Restarting your host would be the easiest way to ensure of this.

2. Run`VirtualBox7_Integration.exe`. Ensure that the correct VM is set to `Enabled`

3. Run `vmmon64.exe`

4. Use `VirtualBox7_Integration.exe` to launch VirtualBox

5. Launch the virtual machine from VirtualBox

I tried to follow your instructions, step by step, but unfortunately the VM remains in stuck

4d61726b commented 10 months ago

In your guest VM can you:

  1. Boot into Windows normally, no debugging
  2. Right click kdcom.dll in C:\Windows\System32
  3. Click Properties
  4. Click the Details tab
  5. Screenshot and post it here

Additionally, can you run winver in your guest VM and post the screenshot here as well?

What version of VirtualBox are you running?

0xbadb0d00 commented 10 months ago

In your guest VM can you:

1. Boot into Windows normally, no debugging

2. Right click `kdcom.dll` in `C:\Windows\System32`

3. Click `Properties`

4. Click the `Details` tab

5. Screenshot and post it here

Additionally, can you run winver in your guest VM and post the screenshot here as well?

What version of VirtualBox are you running?

kdcom version details inside guest:

VirtualBoxVM_DnelBLBRLs

Winver inside guest:

VirtualBoxVM_5fqndlChJo

VirtualBox Version: immagine

4d61726b commented 10 months ago

Thanks for the info. I was able to reproduce this issue with your environment.

I would need some time to try and triage this, but it may be a while until I get to it. In the meantime, you can always use Windows 11 on VMware Workstation. That still works perfectly.

VirtualBox has always been a second-class citizen on this project because it's not something I ever use.

0xbadb0d00 commented 10 months ago

Thank you @4d61726b

4d61726b commented 10 months ago

@giudon010 I had some free time to look into this and track down the problem. At first glance, it appears that there is a discrepancy between the monitor and the guest with regard to the physical address of the buffer that holds the RPC channel data in the guest.

As a temporary workaround, can you reduce the memory to 2048mb in the guest and let me know if you are able to get further?

SoleimanyBen commented 10 months ago

@4d61726b I'm running into the same issue on VMWare Workstation with my VM running Windows 11.

I went ahead and reduced my VMs memory to 2048mb, but it still just hangs on startup. If I don't try and boot the OS with driver signature enforcement enabled, the OS boots just fine.

I also checked my kdcom.dll details, and it matches what @giudon010 posted.

4d61726b commented 10 months ago

@SoleimanyBen I have not yet been able to reproduce this symptom in VMware Workstation. The issue experienced here is in the VirtualBox part of the code which is not shared with VMware Workstation.

  1. What version of VMware Workstation are you running?
  2. Can you give me the Windows version in the guest from winver?
  3. Do you have Hyper-V enabled on your host? The easiest way to determine this is if you go to your Virtual Machine settings, click the "Options" tab, and select "Advanced". Look for the following:
image

Regardless of whether it's selected or not, then the answer is "Yes". If you don't even see that option available, then the answer is "No".

0xbadb0d00 commented 10 months ago

@giudon010 I had some free time to look into this and track down the problem. At first glance, it appears that there is a discrepancy between the monitor and the guest with regard to the physical address of the buffer that holds the RPC channel data in the guest.

As a temporary workaround, can you reduce the memory to 2048mb in the guest and let me know if you are able to get further?

The workaround works!!! Thank you for your time and work @4d61726b

SoleimanyBen commented 10 months ago

@SoleimanyBen I have not yet been able to reproduce this symptom in VMware Workstation. The issue experienced here is in the VirtualBox part of the code which is not shared with VMware Workstation.

1. What version of VMware Workstation are you running?

2. Can you give me the Windows version in the guest from `winver`?

3. Do you have Hyper-V enabled on your host? The easiest way to determine this is if you go to your Virtual Machine settings, click the "Options" tab, and select "Advanced". Look for the following:
image

Regardless of whether it's selected or not, then the answer is "Yes". If you don't even see that option available, then the answer is "No".

@4d61726b Thank you for the reply :)

It actually turns out that it was an old version of VMWare Workstation that was causing the issue. I am not entirely sure what version of VMWare Workstation I was previously on, but once I upgraded to 17.5.0 build-22583795 everything worked as was expected.

4d61726b commented 7 months ago

This issue has been addressed in 2024.0. Running the new vminstall.exe in Windows 11 now has the option to patch winload which will force it to map the early boot modules into a lower physical address range.

The issue was that kdcom.dll was getting physically mapped to a range where the upper half of the address were not all zeroes. This broke the VirtualBox RPC mechanism.

The end result of this fix will allow you to run Windows 11 with any amount of RAM configured. You will no longer need to set it to a low value that previously suggested as a workaround.