Mov AX, 0xDEAD

@Dietmar I will check last acpi.sys in VM x64 with multiple cpu and acpi007 definitions. If bsod will not triggered - your dsdt is much complex, as i remember you have external COM card, try to setup with it

Oh, i forget about x32 only lan debug and without COM hardware card/port it is not possible at all

Let me see on kernel log(lite and full) if it possible

Who is the author of this driver ? Not MS ? I surprised why stack is not overused on later OS, limit is same 12kb

@Dave-H There is no hanging restart workaround (ported storport.sys from win8 has same problem if usb3 storage inserted), no point to wait this specific fix from current acpi driver

@UsefulAGKHelper Original razzle is ideal to compile anything from leaked sources, just cd to directory and build any .sys/.exe/.dll To show BSOD info on UEFI screen i think a lot of things need to rewrite or create from scratch, technicaly BSOD screen is text screen rendered by bios fonts, so in win8/win10 no more text mode, only hires screen with bsod code

@Dietmar This is 100% stack problem, ba234fc4 < ba235000 I made little table based on @Andalu debug log (if we can trust to windbg log), even MS drivers sometime allocate stack memory above 400 bytes, of couse NVMe is badly written, it request most of all: 2728 bytes ! Stack size NVMe+0x13985 5908 22792 40 NVMe+0x135e5 5930 22832 16 storport!DllInitialize+0x2e1 5940 22848 44 storport!DllInitialize+0x1e55 596c 22892 24 storport!DllInitialize+0x20d9 5984 22916 40 HAL3!HalBuildScatterGatherList+0x202 59ac 22956 48 storport!DllInitialize+0x5d25 59dc 23004 64 storport!DllInitialize+0x2175 5a1c 23068 16 storport!DllInitialize+0x21c5 5a2c 23084 32 storport!StorPortExtendedFunction+0x5fcd 5a4c 23116 64 storport!DllInitialize+0x7301 5a8c 23180 32 storport!StorPortExtendedFunction+0x3988 5aac 23212 32 storport!StorPortExtendedFunction+0x671e 5acc 23244 28 storport!DllInitialize+0x645b 5ae8 23272 24 nt!IopfCallDriver+0x51 5b00 23296 20 CLASSPNP!SubmitTransferPacket+0x82 5b14 23316 48 CLASSPNP!ServiceTransferRequest+0xe4 5b44 23364 36 CLASSPNP!ClassReadWrite+0xff 5b68 23400 24 nt!IopfCallDriver+0x51 5b80 23424 20 MirDisk+0x1b6e 5b94 23444 24 nt!IopfCallDriver+0x51 5bac 23468 16 PartMgr!PmReadWrite+0x2f 5bbc 23484 24 nt!IopfCallDriver+0x51 5bd4 23508 28 ftdisk+0x11c6 5bf0 23536 24 nt!IopfCallDriver+0x51 5c08 23560 16 VolSnap!VolSnapRead+0x26 5c18 23576 24 nt!IopfCallDriver+0x51 5c30 23600 16 Ntfs+0x11c3 5c40 23616 480 Ntfs+0xd26 5e20 24096 224 Ntfs+0x36f6 5f00 24320 432 Ntfs+0x300a 60b0 24752 56 nt!IopfCallDriver+0x51 60e8 24808 20 nt!IopPageReadInternal+0xf3 60fc 24828 32 nt!IoPageRead+0x1b 611c 24860 132 nt!MiDispatchFault+0x691 61a0 24992 108 nt!MmAccessFault+0xdde 620c 25100 0 nt!KiTrap0E+0xdc 620c 25100 216 nt!CcMapData+0x137 62e4 25316 32 Ntfs+0x26a6e 6304 25348 116 Ntfs+0x26c89 6378 25464 56 Ntfs+0x26b96 63b0 25520 56 Ntfs+0x26aed 63e8 25576 176 Ntfs+0x3573d 6498 25752 216 Ntfs+0x3535c 6570 25968 600 Ntfs+0x356f5 67c8 26568 228 Ntfs+0x25f2d 68ac 26796 100 nt!IopfCallDriver+0x51 6910 26896 232 nt!IopParseDevice+0xb6a 69f8 27128 120 nt!ObpLookupObjectName+0x590 6a70 27248 84 nt!ObOpenObjectByName+0x140 6ac4 27332 124 nt!IopCreateFile+0x43b 6b40 27456 96 nt!IoCreateFile+0xd4 6ba0 27552 780 win32k!EngGradientFill+0x7a7e 6eac 28332 60 win32k!EngQuerySystemAttribute+0xa03 6ee8 28392 52 win32k!EngLoadModule+0x9a 6f1c 28444 16 win32k!EngLoadModule+0xf 6f2c 28460 100 ativvaxx!vMMDLLInitFuncs+0x8290 6f90 28560 436 ativvaxx!vMMDLLInitFuncs+0x32450 7144 28996 40 ativvaxx!vMMDLLInitFuncs+0x30c5f 716c 29036 28 ativvaxx!vMMDLLInitFuncs+0x2e12f 7188 29064 20 ativvaxx!vMMDLLInitFuncs+0x1a69a 719c 29084 32 ativvaxx!vMMDLLInitFuncs+0x20985 71bc 29116 16 ativvaxx!vMMDLLInitFuncs+0xf6e3 71cc 29132 84 ativvaxx!vMMDLLInitFuncs+0xf65f 7220 29216 232 ativvaxx!vMMDLLInitFuncs+0x5734 7308 29448 28 ativvaxx!vMMDLLInitFuncs+0x5c36 7324 29476 20 ativvaxx!vMMDLLInitFuncs+0x5bdc 7338 29496 72 ati3duag!bDdHslVideoMemoryFree+0x22e7 7380 29568 568 ati3duag!bDdHslVideoMemoryFree+0x7eb4 75b8 30136 24 ati3duag!bDD4DISPInitDD+0x72 75d0 30160 40 ati2dvag+0x17b09 75f8 30200 888 ati2dvag+0x18070 7970 31088 80 win32k!EngQuerySystemAttribute+0x5b4 79c0 31168 72 dxg!vDdEnableDriver+0x8a 7a08 31240 28 dxg!DxDdEnableDirectDraw+0xbf 7a24 31268

.

@Dietmar 1) run !thread after BSOD to see stack limits 2) you cannot change sub esp, 0AA8h without rewriting code after 3) nvme.sys must be patched to execute MmGrowKernelStack() somewhere in init phase when storport called us: 4) where is .pdb for this nvme.sys ?

@Dietmar I still thinking this is stack problem: 1) 413976 - some procedure entry inside nvme,sys, esp at this point is ba294f9c+AA8= BA295A44 or BA295A40 or BA295A48 It allocate local buffer on kernel stack with size AA8 = 2728 Bytes I think stack pool ended at BA295000, 4k aligned ba294f9c is below stack pool so get BSOD when driver PUSH ESI to this memory 2) Win7/Win8 kernels have kernel KeExpandKernelStackAndCallout(), it is emulated by NTOSKRNL Emu_Extender If nvme uses it and some wrong with emulation code (i never tested this procedure) -> driver tried to allocate more stack pool, but really it was not happen, so stack is same size.

On same IRQ can be many devices, this is concept, when irq signal triggered, windows call handler for each driver in cycle. Driver then check hardware registers of device and if it say "interrupt was not initiated by my device", windows call next driver, etc. i think problem in nvme/storport itself, maybe it expects MSI type of interrupt or uses too much stack memory or some else cannot help with this, i don't know how pci.sys works

Seems stack problem, driver push esi to memory at 0xba294e60, but this memory is paged/unavailable and kernel get double fault case EDIT: 0xba294e60 is not aligned to 4K, so there is no stack overflow issue, windbg probably failed to show exact opcode position Example at acpi:DriverEntry(): stack pool size = f9dc1000 - f9dbe000 = 3 * 4K =12kb currently used = f9dc1000 - f9dc07d4 = 0x82C bytes = 2kb why esp <> Current f9dc07d4 i don't know

@Dietmar try to disable multi-threads, but it changed OS behaviour boot.ini : /ONECPU

@Andalu on last screen ntkrpamp.pdb also opened where windbg installed, i think this is wrong, yes windbg create copy of active *.pdf in own directory, but inside folder /sym/name.pdb/*GUID*/name.pdb :

SHA-1 0e36... OK SHA-1 14a5... OK GUID path on screen - Wrong ntkrpamp.exe v5.1.2600.7581 (SHA-1 14A56010EDEAED3B171CC9B836BF274DD26D0995) has PDB info:

@Andalu On HOST pc run "process monitor/file monitor" from SysInternals , look where windbg try to find .pdb for ntkrpamp.exe

Bless Andalu for providing kernel log with bug tips Bug was overwriting pointer to next AML operator for most device definition

@Andalu, @Damnation Please check last version, i hope there is no more BSOD regression since v6 buged patch

Hi All Sorry fo v6, it was bugged Please check fixed: pre-v7 XP: https://pastebin.com/C5NXwHbS pre-v7 W2003: https://pastebin.com/8QURrM49

in boot.ini boot from c:\windows, strange, but OK unfortunately your windbg print "Could't resolve error at 'ed Kd_ACPI_Mask 0xFFFFFFFF' ", i never get this error I recommend: 1) set ONE directory for symbols _NT_SYMBOL_PATH = srv*c:\ACPI\SYMBOLS*http://msdl.microsoft.com/download/symbols c:\ACPI\SYMBOLS change to your favorite path, for example W:\Symbols4 (you must have W: on usb-drive/ other partition/etc) place halmacpi.pdb and ntkrnlmp.pdb/ntkrpamp.pdb at c:\ACPI\SYMBOLS\halmacpi.pdb\9875FD697ECA4BBB8A475825F6BF885E1\halmacpi.pdb, c:\ACPI\SYMBOLS\ntkrnlmp.pdb\FB6BF595C0344379B369466C1ED25FCB2\ntkrnlmp.pdb, c:\ACPI\SYMBOLS\ntkrpamp.pdb\7D6290E03E32455BB0E035E38816124F1\ntkrpamp.pdb 9875FD697ECA4BBB8A475825F6BF885E1 - internal hash of original halmacpi.dll, XP sp3 v5512, english, size= 134400 FB6BF595C0344379B369466C1ED25FCB2 - ntkrnlmp.exe, v5512, size= 2 145 280 7D6290E03E32455BB0E035E38816124F1 - ntkrpamp.exe, v5512, size= 2 023 936 2) auto download pdb on host PC, but halmacpi.dll/ntkrnlmp.exe/ntkrpamp.exe/hal3.dll/renamed.exe must be taken from target pc: "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\symchk.exe" /v halmacpi.dll "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\symchk.exe" /v ntkrnlmp.exe "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\symchk.exe" /v ntkrpamp.exe symchk.exe place files to _NT_SYMBOL_PATH environment path, but better recheck where files stored 3) if you place .pdb properly, you will not see "Symbol file could not be found ntkrpamp/hal3"

@Dietmar To avoid every time when debugging: As i remember some devices in dsdt return zero resources and acpi detect it as Assertion

from wiki: So MS may use this partition as blob without fillesystem and probably Disk Manager GUI hides it to keep metadata from destroying

breakpoint was failed to set Why need .pdb at proper place? Because on target PC you need acpi.sys, on host PC need acpi.pdb Open your acpi.sys, look for string ".pdb", you will see path where windbg will look for acpi.pdb on host PC. I compile always to c:\acpi\acpi_sp1\base\busdrv\acpi\driver\nt\obj\i386\acpi.pdb, Dietmar compiles to other path, that's why need two files in a bundle for debugging, you need place .pdb to same path where it was compiled

@WinWord2000 Stop asking me about windows 2000, I have already answered what you need to do to get ACPI 2.0 on it, look for people who will do this, not me

@Andalu AMLILoadDDB is generic AML Interpreter error, it means some error when DSDT/SSDT processed I ask you make log with debug mode, you can load old PM with me to detailed steps: 1) use checked(debug) acpi.sys v6, place .pdb to path where acpi.sys was compiled (path is compiler depend) 2) set breakpoint bu acpi!DriverEntry 3) after breakpoint triggered, enable lite debug mode ed Kd_ACPI_Mask 0xFFFFFFFF 4) if lite mode doesnt show more info, use additional heavy debug mode !amli set spewon verboseon logon traceon but be carefull, it can make log for long time