Mov AX, 0xDEAD

AcpiArbCrackPRT() is decoder for IRQ routing, description tell about some "link nodes" It called many times, so best to keep it running when pci was loaded You can after patching set breakpoint to AcpiArbCrackPRT() and pci!entry to see how ofter it was called before and after loading pci i dont know :) i think acpi report to kernel about some device, kernel try to get irq routing for it immediatly yes, see kernel is requester to first call to AcpiArbCrackPRT() and always only after pci was started

@Dietmar Can you prepare logfile before this BSOD ? use Kd_ACPI_Mask 0xFFFFFFFF

LinkNodeCrackPrt() rewritten from scratch, we can't use it, without deep debugging there is no possible to find root of problem Workaround for this BSOD, change in irqarb.c ASSERT(PciInterfacesInstantiated); to this simple condition allows AcpiArbCrackPRT() skip processing until pci.sys will not be loaded

I played a little in IDA with XP in Virtualbox with full loading to destop Execution order 1) ntoskrnl.exe.IopBootAllocation() -> nt.ArbArbiterHandler() acpi.DriverEntry() ntoskrnl.exe.IopBootAllocation() -> nt.ArbArbiterHandler() ntoskrnl.exe.IopBootAllocation() -> nt.ArbArbiterHandler() 2) pci.DriverEntry() 3) ACPIDispatchIrp() (pci.sys/ntoskrnl send irp to acpi) -> ACPIInternalGetDispatchTable() - set dispatch table as AcpiPdoIrpDispatch[] -> call dispatchTable->PnpStartDevice() = ACPIBusIrpStartDevice() 4) ntoskrnl.exe.IopBootAllocation() -> pci.ArbArbiterHandler() 5) ntoskrnl.exe.IopBootAllocation() - cycle to run may arbhandlers 1) ->acpi.ArbArbiterHandler(arbiter.lib) ->acpi.AcpiArbBootAllocation() ->acpi.ArbBootAllocation(arbiter.lib) ->acpi.AcpiArbPreprocessEntry() ->acpi.AcpiArbAddAllocation() ->acpi.AcpiArbCrackPRT() 2) -> pci.ArbArbiterHandler() 6) ntoskrnl.exe.IopBootAllocation() ->acpi.ArbArbiterHandler(arbiter.lib) .... ->acpi.AcpiArbCrackPRT() 7) ... IRP from PCI/OS to ACPI: WINDBG>!irp 81BEA008 Irp is active with 2 stacks 1 is current (= 0x81bea078) No Mdl: No System Buffer: Thread 81bcc788: Irp stack trace. cmd flg cl Device File Completion-Context >[ 1b, 0] 0 e1 81b69f18 00000000 f99ac202-f9e6b2b4 Success Error Cancel pending \Driver\ACPI pci!PciSetEventCompletion Args: e1451718 e14539f0 00000000 00000000 [ 1b, 0] 0 0 81b69728 00000000 00000000-00000000 \Driver\PCI Args: e1451718 e14539f0 00000000 00000000 MajorFunction = IRP_MJ_PNP MinorFunction = IRP_MN_START_DEVICE

@daniel_k not sure, issue can be anything due async logic in driver, last sucessfull line: Someone asked acpi to give GUID of some inteface for this device and responce was OK, (or acpi asked to someone, i dont know details). We dont know what happens after because acpi.driver doesn't have debug output in each functions. We know about calling to AcpiArbCrackPRT(), but there is no pevious call to ACPIBusIrpStartDevice() before

Thanks, seems acpi have problem on dispatcher level or other place, i have no glue at present time, need some time to read source...

loading pci.sys may be postponed, so we need be 100% sure about execution order

1) instant stop with /BREAK option 2) PDB for pci.sys must be accesable by windbg (i think this is done, it download it from MS Symbol server first time) 2) bu pci!DriverEntry bu acpi!DriverEntry bu acpi!AcpiArbInitializePciRouting bu acpi!ACPIBusIrpStartDevice 3) check breakpoint list bl 4) press g few times until you reach BSOD / Assert question / ACPIBusIrpStartDevice()

We don't know even ACPIBusIrpStartDevice was called or not...

@Dietmar Set 4 breakpoints as my example and trace ACPIBusIrpStartDevice manualy step-by-step(F10) if you reach it before BSOD, source window will open only if windbg was started on PC where sources was compiled

@Dietmar tracing on vm with "free" pci.sys kd> bl 0 eu 0001 (0001) (pci!DriverEntry) 1 eu 0001 (0001) (acpi!DriverEntry) 2 eu 0001 (0001) (acpi!AcpiArbInitializePciRouting) 3 eu 0001 (0001) (acpi!ACPIBusIrpStartDevice) 1) acpi entry point 2) pci.sys entry point 3) called ACPIBusIrpStartDevice() 4) deviceExtension->Flags & DEV_CAP_PCI is 1, we call AcpiArbInitializePciRouting() 5) status = ACPIInternalSendSynchronousIrp(topDeviceInStack, &irpSp, &buffer); return status =0 = OK , then we set PciInterfacesInstantiated = TRUE;

Thanks, i was wrong, pci bus has proper names

@Dietmar I think i found what is wrong - pci root bus don't have name PNP0A03 -> acpi.sys didn't set DEV_CAP_PCI property -> no call to AcpiArbInitializePciRouting( DeviceObject ), thanks to @Damnation for tip with DEV_CAP_PCI ! Dietmar, can you share dsdt table from this amd board?

Mixed output: yes, acpi started first, but why bsod before loading pci - i don't see reason probably problem in acpi.sys inside - it never call AcpiArbInitializePciRouting(), no request to pci, etc

@Dietmar you missed something with pci.sys i have insant output without any additonal commands, just g g

Ok, remote kernel debugging is complicated, give me few days to prepare all things

@Dietmar I didn't found how enable logging pci.sys by official way, need manual patch pci.sys 5.1.2600.5512 size 159616 sha1 4de5522539149d32d8508d51cc2a014302c78e75 file offset 0xB020 0x00 0x00 0x00 0x00 -> 0xFF 0xFF 0xFF 0x7F then recalc driver checksum with any util sha1 of patched pci.sys bde4352e853e45137b5dc33e0f9846337b41950c No need enter KD_PCI_Mask anymore, but keep KD_ACPI_Mask on You also can remove previous patch from IsTraceOn(), no need to see ValidateArgTypes() at present time After i got what wanted output:

@Andalu Good, 1) what LAN chip do you have on problem H470 board ? (realtek/intel/...) 2) I will prepare requires files for you in PM

yes, no any output from pci.sys, i will update how to force pci.sys to tell Tracename - it's acpi.sys only feature for some functions, thanks to MS for it ! ed Kd_XXX_Mask 0xFFFFFFFF- is standart way to enable extra logging any checked driver

@Andalu Do you have second PC, LAN cable and free time to investigate this bsod ? You will need setup remote debug connection between two PC and save log files

,

line 3512: line 3518: So we have NULLed PciInterfacesInstantiated and NULLed AcpiArbiter.ArbiterState.Extension->InterruptRouting PciInterfacesInstantiated can be setted only on one place, AcpiArbInitializePciRouting(): pci.sys reject our IRP request and answer with some error what acpi reqest: Seems to be complex problem, i think 1) acpi doesn't configured PCI properly before, send irp to pic, pci.sys failed some pre-checks 2) acpi configured PCI properly, but pci.sys still requires certain conditions @Dietmar Without logging, i can't help with this, compile acpi.sys and replace pci.sys(SP3-KB936929-x86-CHK-enu.exe or sp3 checked iso if you have) to checked versions, enable full loging ed Kd_ACPI_Mask 0xFFFFFFFF ed Kd_PCI_Mask 0xFFFFFFFF - don't sure about this cmmand, i never debugged pci driver

@Dietmar ACPIPrint( ( ACPI_PRINT_CRITICAL, "message - %d \n", status ) ); 3 and 4 lines is just printf() with variable argument count

@Damnation struct _ObjData, integers share same space, so they declared as union on XP it has dwDataValue/uipDataValue to store Int32 integer on W2003 uipDataValue was deleted since Longhorn, new field was added qwDataValue to store Int64 ineger This is hard job All functions which deal with dwDataValue/uipDataValue , including calculation size like sizeof(ULONG), sizeof(LONG), ... Most simple/ugly way - rename dwDataValue/uipDataValue field , compile, you see most errors/places where integers was used, but code is tricky, it can works with pointer to ULONG, you won't see direct acces to field

@Dietmar Nice, no more "buffers", all variables are integers (not 64-bit as it should, but it is best what xp1 sources can offer) I will update first post later Done