search

4d61726b / VirtualKD-Redux

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

Is Win7 still supported? #44

Closed rodwiddowson closed 2 years ago

rodwiddowson commented 2 years ago

More of a query than a bug report.

I recently had to comission a test VM for Win7 (which was another story if pain). Once I had it as I wanted it my next step was to try to get virtualKD working .... and it didn't.

I could probably do some more diagnosis if you would like me to; but a "nope, we've moved on" also works (I just reverted to my pre-VirutalKD snapshot and set up the serial port)

4d61726b commented 2 years ago

The VirtualKD-Redux policy for guests has always been to never (intentionally) break compatibility with guest OSes. VirtualKD-Redux will always support as old as Windows XP RTM (something the original VirtualKD doesn't support) up to the latest version of Windows, currently Windows 11.

The VirtualKD-Redux policy for hypervisors has always been to only support the non-EoL'd versions of hypervisors. If you are using an ancient version of VMware Workstation or VirtualBox, then it's a good idea to try and keep that updated for security.

The same goes for your host OS. If the non-EoL'd hypervisor still runs on your host OS, then it is still supported.

Back to your original issue. Can you give me more information about your test environment so I can try and reproduce it? The issue template has most of the questions on there that would help me reproduce the problem. Thanks.

rodwiddowson commented 2 years ago

Can you give me more information about your test environment

Sure.

The client has had nothing installed except as noted above. I ran VmInstall.exe rebooted, turned off signature checking (which I do habitually - remembering always that in Win7 it is selected with just two up arrows, not the three that Win10 needs). and it reboots but without vmmmon64 noticing the OS and hence throwing up Windbg.

One thing I did notice - but which I suspect is expected - is that when I turned on serial debugging that didn't work either. I had to revert the VM to my "about to install VirtualKD" snapshot before I could get that working.

Don't hesitate to ask for more info.

... And a huge thank you for providing such an important tool and being so responsive in its support.

rodwiddowson commented 2 years ago

I'm not sure what's happening but i think that

I'm not100% sure of the repeatability of all this (for instance I have a suspicion that shutting down and powering off the VM and closing VMMON64 and any debuggers) will have a different effect to just rebooting the client because the pipe doesn't necessarily go away.

I hope that this give you more to go on. Jusrt ask if you want targeted experiments performed.

4d61726b commented 2 years ago

I've been trying to reproduce it but have had no luck yet.

it reboots but without vmmmon64 noticing the OS and hence throwing up Windbg.

To clarify, you're saying that you don't see any PID / row for the running VM in the vmmon GUI? A new row will get created in that window when a monitor (vmware-vmx.exe) starts on the host system. The rows then get further populated with information as the debug session gets established between guest and host.

rodwiddowson commented 2 years ago

I Reverted my VM, installed 2022.0 and the wretched thing worked. So it must have been PEBKAC somewhere (but I don't see where). The only difference being that an update happened (probably the "Windows7 is no longer supported whine").

lets call this closed and a huge apology for wasting your time