You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, in vmmon64, I can't get the "OS" column to say "yes" upon start-up.
It is interesting that when I shut down the guest OS, the OS column turns into "yes" - and then a brand new entry pops up - the row that has "yes" is an unusable, old entry, it seems.
In the host, the entry in the VM description file looks like:
In the guest VM, I captured a log of the operation performed by vminstall, using Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) -- see attachment Logfile.zip. There I can see that the installer overwrote kdcom.dll, at timestamp 2:48:39.9596648.
I can further confirm that by looking at the directory contents of windows\system32 - see attached dir.txt.
Also having this issue with VMWare on Windows 10 pre and post anniversary builds. After running vminstall.exe only on shutdown does the OS column say yes.
Following instructions made it work for me in VMWare on pre-anniversary, haven't tried post yet:
VM: Copy kdbazis.dll and kdpatch.sys to C:\Windows\System32\drivers
from virtualKD\target\x86 or x64.
VM: Run kdpatch.reg
VM: In an admin command prompt run:
bcdedit /debug on
bcdedit /dbgsettings serial
Followed instructions per:
http://virtualkd.sysprogs.org/tutorials/install/
However, in vmmon64, I can't get the "OS" column to say "yes" upon start-up.
It is interesting that when I shut down the guest OS, the OS column turns into "yes" - and then a brand new entry pops up - the row that has "yes" is an unusable, old entry, it seems.
In the host, the entry in the VM description file looks like:
In the guest VM, I captured a log of the operation performed by vminstall, using Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) -- see attachment Logfile.zip. There I can see that the installer overwrote kdcom.dll, at timestamp 2:48:39.9596648.
I can further confirm that by looking at the directory contents of windows\system32 - see attached dir.txt.
dir.txt
Logfile.zip
The text was updated successfully, but these errors were encountered: