VM Failing to Reboot
-
dinhngtu I got into Safe Mode, then did nothing and just rebooted, result was still the same BSOD.
-
kagbasi-ngc It worked on my VM when I tried that procedure on my local lab system. Unfortunately without a closer inspection I can't tell what's going on. If you still want to recover the VM, I'd start at removing all the non-inbox drivers.
-
dinhngtu I’m not sure I understand what you mean by
non-inbox drivers.I will talk with our ISSO to see if sending an export of the VM is allowable. If not, would you be interested in a video call where we can troubleshoot in realtime?
-
kagbasi-ngc I think for that it'd be more appropriate to contact our support team, which will be able to help you directly on your infrastructure. I'd also like to keep any troubleshooting information on the forum in case someone runs into a similar problem.
Non-inbox drivers mean drivers with "Inbox : No" as seen in your screenshot.
-
dinhngtu Roger that, agreed.
I just got back to the lab, so I'm gonna try and remove those
non-inbox driversand see what happens. -
dinhngtu Unfortunately, I don't have good news. I removed all the
non-inbox drivers, one by one (rebooting after removing each one), yet still the VM is crashing with the same BSOD message. -
kagbasi-ngc Could the VM get into Safe Mode?
-
dinhngtu Yes, it does. There is no
Last Known Good Stateoption however. -
kagbasi-ngc The fact that your VM still boots in Safe Mode means that there's still some drivers blocking Windows from booting in normal mode. Please enable boot logging by running
bcdedit /store bcd /set {default} bootlog yesthen post the boot logs of normal mode versus safe mode. This log is found atC:\Windows\ntbtlog.txt.Could you send another copy of your SYSTEM hive?
-
dinhngtu Just to clarify, the VM isn't booting into Safe Mode; I have to trigger it by smashing the F8 key at boot. It boots normally then goes to the BSOD.
I will get the logs for you shortly. Do you want me to drop them in the same location you sent earlier?
-
kagbasi-ngc Just to confirm, if you use the F8 menu it boots into Safe Mode without getting a BSOD, right? Please upload the SYSTEM hive to the same location.
-
dinhngtu Yes, it does. The only time I get the BSOD is if I allow the VM to boot normally without interfering.
-
dinhngtu So I managed to enable the boot logging, allowed the VM to do a normally boot to BSOD, then I booted with Hiren's, however, I'm not seeing the log file at C:\Windows.
-
kagbasi-ngc You might need the debugger in normal mode. Attach the debugger right at boot time and run the following command (beware the exact spelling):
sxe -c "lm1mna (poi(rdx));g" ldClick Go until Windows loads completely or until you get a VM crash in Windbg, then paste the entire Windbg output.
-
dinhngtu sorry for the delayed response, having trouble getting the debugger to reattach. I've re-input all the boot parameters, yet still, no data is being piped to the debug port on the host.
Do you think perhaps the removal of the drivers we did yesterday has removed the VM's ability to talk to the host?
-
kagbasi-ngc It shouldn't, the debugger drivers are built into Windows. If you're having issues with attaching the debugger, you can get into the F8 menu, start attaching WinDbg then choose Debugging mode in the F8 menu to start the guest. This should give WinDbg the correct timing to attach to the guest.
-
dinhngtu thanks for the pointers, but nothing I'm doing seems to be working. The debugger seems to have connected to the host successful, but the VM isn't transmitting any data to the debugport.
-
kagbasi-ngc Does it get stuck at "Waiting to reconnect..."? Do you get anything when telnet-ing to the VM's serial port?
-
dinhngtu Yes (see image below). I'm on my way back to the office now, should be there in about 45 mins and will try telnet to the host tcp port 7001 and see what I get.
-
dinhngtu said in VM Failing to Reboot:
Do you get anything when telnet-ing to the VM's serial port?
Sorry for the delayed response. I just attempted to telnet to the VM's serial port on the host, while watching IPTables, and here's the behavior I observed:
-
The PuTTY telnet session remains open while the VM is powered up and attempting to boot.
-
As soon as the BSOD is encountered and the VM powers off, the telnet session window terminates.
-
While watching IPTables, I can see the pkts count increment by 5 each time I attempt a connection.
Given the above observations, I'm convinced that the host is setup correctly, but it's the VM that is not dumping any data to the serial console on the host.
This is the IPTables rule I was watching:
Chain xapi-INPUT (1 references) pkts bytes target prot opt in out source destination 70 3636 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:7001 -