Debugging ACPI BIOS ERROR with WinDbg

Question

I'm trying to debug the ACPI BIOS ERROR stop code on the Windows 10 installation media. I am unable to find a way to enable the BSOD screen to show more detailed information, so I thought I would use WinDbg.

I enabled /debug on the USB stick that contains the Windows 10 installer

bcdedit /store h:\efi\microsoft\boot\bcd /boot {default} on

I also configured serial debugging:

bcdedit /store h:\efi\microsoft\boot\bcd /dbgsettings SERIAL debugport:1 baudrate:115200 /start ACTIVE

When I connect with the debugger I see the following:

Microsoft (R) Windows Debugger Version 10.0.19041.685 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\com9
Waiting to reconnect...
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 19041 x64 target at (Fri Jan 15 13:30:07.901 2021 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.
Symbol search path is: srv*
Executable search path is: 
Unable to read PsLoadedModuleList

Then it says Debugee not connected.

If I try WinDbg Preview I get the same output.

If I try with AUTOENABLE

bcdedit /store h:\efi\microsoft\boot\bcd /dbgsettings SERIAL debugport:1 baudrate:115200 /start AUTOENABLE

The debugger never attaches. I see the windows logo and the spinning wheel, and then it stops spinning. Using PuTTY to look at the serial output, I never see the "Waiting for debugger to attach" message.

Does anyone have any recommendations on next steps? Ideally I could avoid the debugger and get the specific ACPI BIOS error, but I'm not sure how to spit out the information onto the screen or the serial console.

Thanks

1/16/2020

I was finally able to get the kernel attached. This was with /bootdebug {default} on, /debug {default} on, and /start ACTIVE.

Microsoft (R) Windows Debugger Version 10.0.20153.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\com9
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 19041 x64 target at (Sat Jan 16 15:58:25.274 2021 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.  (Initial Breakpoint requested)

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
ReadVirtual() failed in GetXStateConfiguration() first read attempt (error == 0.)
Windows Boot Debugger Kernel Version 19041 UP Free x64
Machine Name:
Primary image base = 0x00000000`00dcd000 Loaded module list = 0x00000000`00f74a30
System Uptime: not available
winload!DebugService2+0x5:
00000000`00f34915 cc              int     3
kd> .lastevent
Last event: Load module winload.efi at 00000000`00dcd000
  debugger time: Sat Jan 16 15:58:25.122 2021 (UTC - 7:00)
kd> lm
start             end                 module name
00000000`00dcd000 00000000`00fcd000   winload    (pdb symbols)          C:\ProgramData\Dbg\sym\winload_prod.pdb\EB17EB295A5D7C42A040B685BA7087412\winload_prod.pdb
kd> !analyze -v
Module Load Event - In-depth analysis is not supported
kd> .bugcheck
Unable to resolve nt!KiBugCheckData
Unable to read bugcheck data
kd> g
Shutdown occurred at (Sat Jan 16 16:05:35.153 2021 (UTC - 7:00))...unloading all symbol tables.
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 19041 x64 target at (Sat Jan 16 16:05:35.985 2021 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.  (Initial Breakpoint requested)

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
Windows Boot Debugger Kernel Version 19041 UP Free x64
Machine Name:
Primary image base = 0x00000000`00dcd000 Loaded module list = 0x00000000`00f74a30
System Uptime: not available
winload!DebugService2+0x5:
00000000`00f34915 cc              int     3
kd> .bugcheck
Unable to resolve nt!KiBugCheckData
Unable to read bugcheck data
kd> .lastevent
Last event: Load module winload.efi at 00000000`00dcd000
  debugger time: Sat Jan 16 16:05:35.921 2021 (UTC - 7:00)
kd> !analyze -v
Module Load Event - In-depth analysis is not supported
kd> g
Shutdown occurred at (Sat Jan 16 16:05:57.327 2021 (UTC - 7:00))...unloading all symbol tables.
Waiting to reconnect...

The debugger never stopped on the exception :(

Answer 1

These were my problems:

1. My BIOS had SMI serial logging enabled. While booting windows issues several SMIs. So WinDGB was getting confused about the unexpected log messages and causing all sorts of instability.
2. The ACPI problem was coming from the OS, not the boot loaders. This means I only needed /debug {default} on, and /start AUTOENABLE.
3. The OS debugger wasn't working because either a) I had a typo in my DBG2 table (I've now since lost the original), or b) DBG2 doesn't support MMIO UARTs. When I switched to using the standard 0x3f8 IO ports in the DBG2 table, the kernel debugger started working.

From there I was able to use the !analyze -v to debug the ACPI errors and fix them.

Answer 2

Hello,
The !analyze mechanism is not supported in the pre-NT environment (Boot manager, winload.efi, winresume.efi, etc.).

If the information is not spewed to the console by winload.efi, then you won’t be able to see the error (e.g. we usually use ConsolePrint() to print to the console for pre-NT apps, but it’s used only on development code).

It seems that you’re getting a bugcheck at winload.efi, so I’d recommend opening a CSS cases to get assistance further as the private symbols will most likely be needed here.