Dietmar Posted January 1, 2023 Posted January 1, 2023 @Mov AX, 0xDEAD Do you think, that the last device \_SB.PC00.I2C0.HDAC._HID makes the crash? In the Bsod you can see, that it is indeed an _HID so it may be Dietmar PS: The exact number FFFFFADCE4CB5C30 cant be found in Log file.
Mov AX, 0xDEAD Posted January 1, 2023 Author Posted January 1, 2023 12 minutes ago, Dietmar said: AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C2.CAM0._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C4.CAM1._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C2.PMIC._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C0.HDAC._HID) *** Fatal System Error: 0x000000a5 (0x0000000000000003,0xFFFFFADCE4CB5C30,0xFFFFFFFFC0000034,0x000000004449485F) Break instruction exception - code 80000003 (first chance) acpi64v22.txt without bsod: Quote AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C2.CAM0._HID) ="INT3471"FFFFFADCE3E8E010 ACPIBuildProcessDevicePhaseUid: Status = 00000103 AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C4.CAM1._HID) ="INT3474"FFFFFADCE3E8EDB0 ACPIBuildProcessDevicePhaseUid: Status = 00000103 AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C2.PMIC._HID) ="INT3472"FFFFFADCE3E8EA00 ACPIBuildProcessDevicePhaseUid: Status = 00000103 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhaseAdr: Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhaseSta: Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phase6 Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhaseEjd: Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phase8 Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePrw: Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phasea Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePr0: Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phasec Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePr1: Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phasee Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePr2: Status = 00000000 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phase12 Status = 00000000 FFFFFADCE3E8E3B0 5d071100 (0x00000000): ACPIDeviceInternalDelayedDeviceRequest - Transition to D0 FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePsc: Status = 00000103 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhaseAdr: Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhaseSta: Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phase6 Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhaseEjd: Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phase8 Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePrw: Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phasea Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePr0: Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phasec Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePr1: Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phasee Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePr2: Status = 00000000 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phase12 Status = 00000000 FFFFFADCE3E8D010 5d071100 (0x00000000): ACPIDeviceInternalDelayedDeviceRequest - Transition to D0 FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePsc: Status = 00000103 AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C0.HDAC._HID)="INT00000" FFFFFADCE3E8DDB0 ACPIBuildProcessDevicePhaseUid: Status = 00000103 AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.HIDD._STA) AMLI: FFFFFADCE5564040: \_SB.HIDD._STA() FFFFFADCE3E8D970 ACPI\INTC1070 ACPIBuildProcessDevicePhaseHid: Status = 00000103 AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.THC0.TLC1._STA) AMLI: FFFFFADCE5564040: \_SB.PC00.THC0.TLC1._STA() FFFFFADCE3E8C010 1 ACPIBuildProcessDevicePhaseAdr: Status = 00000103 AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.THC0.TLC2._STA) 1) if bsod occurs at random place, my patch is useless, still need finished full log 2) if bsod occurs always at same place, problem is SB.PC00.I2C0.HDAC._HID or next thing _SB.HIDD._STA or some between FFFFFADCE3E8DDB0 ACPIBuildProcessDevicePhaseUid: Status = 00000103
Dietmar Posted January 1, 2023 Posted January 1, 2023 (edited) @Mov AX, 0xDEAD The problem is, that with the debug acpi.sys and windbg connected, no Bsod happens. The only thing is a breakpoint, where you can hit "i" a single time and then XP bit64 boots fast to desktop with all processors, with sound Realtek, full functional. This message The DEBUG acpi.sys connected to Windbg hits Breakpoint 0x7E (0x80000003, xxx, yyy) . *** Assertion failed: The BIOS has reported inconsistent resources (_CRS). Please upgrade your BIOS.NT_SUCCESS(status) *** Source File: c:\win2k3\nt\base\busdrv\acpi\driver\nt\bus.c, line 2802 When you hit "i", it boots to desktop, no other message at all. Edited January 1, 2023 by Dietmar
Mov AX, 0xDEAD Posted January 1, 2023 Author Posted January 1, 2023 (edited) 10 minutes ago, Dietmar said: @Mov AX, 0xDEAD The problem is, that with the debug acpi.sys and windbg connected, no Bsod happens. we can add debug output where a5, (0x3,,C0000034) is used to checked build to see parent device tomorrow i will write what to add if you still want to play with it EDIT: please send me original DSDT in binary form Edited January 1, 2023 by Mov AX, 0xDEAD
Dietmar Posted January 1, 2023 Posted January 1, 2023 @Mov AX, 0xDEAD Of course I want to make this work! Wish you a lot of power and good night Dietmar
Dietmar Posted January 1, 2023 Posted January 1, 2023 (edited) @Mov AX, 0xDEAD Here is raw DSDT from Bios file F22 for the Gigabyte UD z690 DDR4 board. https://ufile.io/ad54jinp Interesting is, that on really ALL z690 boards this Bsod happens. But I also think, that their DSDT's are not so much different, all Intel Dietmar PS: Here is the binary DSDT, fresh read out from running XP 64bit SP2 on this Gigabyte board via ReadwriteEverything 1.7 bit64. https://ufile.io/qe7thwyc Edited January 1, 2023 by Dietmar
UsefulAGKHelper Posted January 2, 2023 Posted January 2, 2023 (edited) On 1/1/2023 at 1:40 PM, George King said: @UsefulAGKHelper You managed VirtualBox and XP x64 debugging right? Yes, I managed to do it using WinDBG preview, you can easily get it from Microsoft Store (for me only the version of windbg from microsoft store works to start debugger on VirtualBox, I don't know why). I got the information from this link: https://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/WINDBG Kernel%26User Mode Debugging/WINDBG Kernel%26User Mode Debugging.md Here's what I have done so far (serial debugging): Quote Settings for exercise: Kernel debugging with Windbg Preview in Host -> debugging Guest VM: Guest VM: CMD as administrator: bcdedit /debug on bcdedit /dbgsettings serial debugport:1 baudrate:115200 (assuming the port is COM1) shut down the VM Go into the settings for our Virtualbox Windows VM: Serial Ports -> Port1 -> Enable serial port Port number COM1 Port Mode -> Host Pipe Uncheck “Connect to existing pipe/socket” Path/Address -> \\.\pipe\MalDBG Start VM HOST: Install Windbg Preview Go to File -> "Start Debugging” and select “Attach to Kernel” Go to COM tab -> Check Pipe and Reconnect Resets 0 Baud Rate 115200 Port \\.\pipe\MalDBG Uncheck Break on connection Click OK - To attach to kernel of our VM For more advice on how to use proper commands to do the debug tests properly on VirtualBox, you can also ask @Mov AX, 0xDEAD and @Dietmar for help. Serial debugging with VirtualBox is what I am familiar. For other types of debugging, you can always ask these two or anyone else experienced with using WinDBG. If BCD is disabled, the following switches for debuging on boot.ini can be found here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/switch-options-for-boot-files#more-information Good luck. Edited January 2, 2023 by UsefulAGKHelper
Dietmar Posted January 2, 2023 Posted January 2, 2023 @UsefulAGKHelper Thanks a lot! I am running Windbg on a checked acpi.sys with guest XP 64 bit, for to solve the crazy Bsod A5 (0x03,..). Over serial cable it is slow. My Log file is now bigger than 40 MB and XP 64 still not booted to desktop, but without(!) error now for 10 hours. I use free ntoskrnl, free hal and DEBUG acpi.sys. But where is problem ): To boot XP SP1 to full desktop using Qemu, on the very first Raspi Pi, needs 24 hours^^. Now I think about the possibility of the build command using razzle . There is an no_opts switch and maybe it works for us, the free acpi.sys comes then without binary "optimization" which propability gives this Bsod Dietmar
UsefulAGKHelper Posted January 2, 2023 Posted January 2, 2023 (edited) 37 minutes ago, Dietmar said: @UsefulAGKHelper Thanks a lot! I am running Windbg on a checked acpi.sys with guest XP 64 bit, for to solve the crazy Bsod A5 (0x03,..). Over serial cable it is slow. My Log file is now bigger than 40 MB and XP 64 still not booted to desktop, but without(!) error now for 10 hours. I use free ntoskrnl, free hal and DEBUG acpi.sys. But where is problem ): To boot XP SP1 to full desktop using Qemu, on the very first Raspi Pi, needs 24 hours^^. Now I think about the possibility of the build command using razzle . There is an no_opts switch and maybe it works for us, the free acpi.sys comes then without binary "optimization" which propability gives this Bsod Dietmar Windows once connected to the debugger, it relies on it to run once it's data shows on the debugger, maybe that's why it's slower. Without debugging, it's much faster because it doesn't rely on the debugger. Obviously without the "optimization", BSOD appears. Obviously, you should still debug ACPI.SYS for testing purposes (using commands to get it to boot without BSOD) but if things take too long to work, then you should also try the same without the debugger so it can show the BSOD faster. Edited January 2, 2023 by UsefulAGKHelper
Mov AX, 0xDEAD Posted January 2, 2023 Author Posted January 2, 2023 @Dietmar Hi, Check PM for new iteration 1
Dietmar Posted January 2, 2023 Posted January 2, 2023 (edited) Hi, anybody here, who knows, how to recover a *.txt file under XP SP3, wish is overwritten from crazy windbg with the same name Dietmar PS: I make a try with Header Signature EF BB BF for *.txt files, put this in Winhex File Type Signatures.txt as Fake for Windows Password pwl , but much too much results. But it works. Get never seen *.txt documents on my compi . So it is only a 12 hours time loss, brr.. Edited January 2, 2023 by Dietmar
Dietmar Posted January 2, 2023 Posted January 2, 2023 (edited) @Mov AX, 0xDEAD Here are the 2 Log files. The free acpi.sys which makes the loong Logfile boots XP SP2 64 bit for the very first time as a free acpi.sys to full desktop, but only with connected Windbg, without same Bsod. The acpi.sys with the short Log file gives this Bsod A5 (0x03, xxx, 0xc00000034,yyy) always. May be, that it is a time problem. At once then I understand, why the debug version of acpi.sys always works: It has all time, means 12 hours for to boot x64. And not a single Bsod happens for the Debug acpi.sys with connected windbg Dietmar Log files https://ufile.io/0r3bmck4 Edited January 2, 2023 by Dietmar
Dietmar Posted January 3, 2023 Posted January 3, 2023 (edited) @Mov AX, 0xDEAD May be GSA1 Bsod, because ObjPath=TZ10,Scope=\_TZ, psz=TZ10 is listed in acpi Log, but TZ10 does not exist in DSDT of the Gigabyte z690 UD 400 DDR4 . I test tomorrow Dietmar EDIT: I delete whole GSA1 in Bios and flash. XP SP3 boots normal, but same Bsod A5 (0x03,..) in XP SP2 bit 64. So, GSA1 does not make this Bsod. Edited January 3, 2023 by Dietmar
Mov AX, 0xDEAD Posted January 3, 2023 Author Posted January 3, 2023 15 hours ago, Dietmar said: @Mov AX, 0xDEAD Here are the 2 Log files. The free acpi.sys which makes the loong Logfile boots XP SP2 64 bit for the very first time as a free acpi.sys to full desktop, but only with connected Windbg, without same Bsod. The acpi.sys with the short Log file gives this Bsod A5 (0x03, xxx, 0xc00000034,yyy) always. May be, that it is a time problem. @Dietmar I think this is multiple threads race condition problem If you filter acpic034mehrtext.txt and keep only c00034 lines, then compare with short bsod log, i will see difference in order it matches at begin, but later difference is random Quote C0000034 #15 C0000034 #8 C0000034 #8 C0000034 #15 C0000034 #8 C0000034 #14 C0000034 #8 vs Quote C0000034 #15 C0000034 #8 C0000034 #8 C0000034 #15 C0000034 #14 C0000034 #8 C0000034 #15 This mean apci is most async, it call other driver and kernel with callbacks, get answer "postponed", after some time event triggered and callback called, so every boot order of execution is not same
Mov AX, 0xDEAD Posted January 3, 2023 Author Posted January 3, 2023 @Dietmar Did you tried v1-v6 version on this board with XP x64 ? Maybe again last processor patch is bugged ?
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now