Dietmar Posted December 21, 2022 Posted December 21, 2022 @Mov AX, 0xDEAD @Damnation @PPeti66x Here is the original and the modded Source file type2op.c for to fake OS from @daniel_k . May be, that this is a little bit too much Dietmar https://ufile.io/2bynpi8j 1
Dave-H Posted December 21, 2022 Posted December 21, 2022 11 hours ago, Dietmar said: @Damnation @PPeti66x Here is the fresh compiled free version of last acpi.sys v7 from @Mov AX, 0xDEAD, compiled with the OS fakes from @daniel_k good luck Dietmar https://ufile.io/e6559bso @Dave-H make try with this acpi.sys on the Flex10. Thanks, I'm about to go away for Christmas for a week now, but I will certainly try it when I get back on the 28th!
George King Posted December 22, 2022 Posted December 22, 2022 @Dietmar What do you mean with OS fake? Do you mean adding all needed OS list? My compiled ACPI have it by default. Without that I cant detect secondary GPU on my laptop.
Damnation Posted December 22, 2022 Posted December 22, 2022 @George King It's the ACPI OS Version lie that daniel_k implemented originally.
Dietmar Posted December 22, 2022 Posted December 22, 2022 @George King Yepp, this is the original OS fake for xp SP3 from @daniel_k, integrated in new acpi.sys via Source code Dietmar
Andalu Posted December 22, 2022 Posted December 22, 2022 @Dietmar Hi, what are the proper commands to give in WinDBG to debug a driver other than acpi.sys?
Dietmar Posted December 23, 2022 Posted December 23, 2022 (edited) @Andalu You have to jump at the driverentry of this driver, exact as for acpi.sys. Then you can trace this driver with hitting t again and again. Also you can check via analyze -v after crash Dietmar EDIT: Sometimes, windbg does not stop at driverentry, even you set a breakpoint there. Then you can use the trick from @Mov AX, 0xDEAD : Change first 2 Bytes in "your driver" at adress driverentry to EB FE via Ida Pro and Winhex. This gives an endless loop. When you hit then "break" in windbg, the compi stops exact at this driverentry. In memory you have to change then back the EB FE to its original values from this driver and hit t again and again. Edited December 23, 2022 by Dietmar
Andalu Posted December 23, 2022 Posted December 23, 2022 @Dietmar thanks for the tips. Unfortunately, I cannot overcome the error "Symbol file could not be found" related to ntkrpamp.exe. I copied it together with ntkrpamp.pdb to any directory but the error is still there. Here is the log: Quote Opened log file 'L:\test2.txt' ************* Symbol Path validation summary ************** Response Time (ms) Location OK c:\ACPI\SYMBOLS Deferred srv*c:\ACPI\SYMBOLS*http://msdl.microsoft.com/download/symbols Microsoft (R) Windows Debugger Version 6.3.9600.17200 X86 Copyright (c) Microsoft Corporation. All rights reserved. Using NET for debugging Opened WinSock 2.0 Waiting to reconnect... Connected to target 192.168.1.3 on port 50000 on local IP 192.168.1.1. Connected to Windows XP 2600 x86 compatible target at (Fri Dec 23 17:36:21.203 2022 (UTC - 6:00)), ptr64 FALSE Kernel Debugger connection established. ************* Symbol Path validation summary ************** Response Time (ms) Location OK c:\ACPI\SYMBOLS Deferred srv*c:\ACPI\SYMBOLS*http://msdl.microsoft.com/download/symbols Symbol search path is: c:\ACPI\SYMBOLS;srv*c:\ACPI\SYMBOLS*http://msdl.microsoft.com/download/symbols Executable search path is: *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe - Windows XP Kernel Version 2600 (Service Pack 3) MP (4 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp.080413-2111 Machine Name: Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720 Debug session time: Fri Dec 23 09:20:51.406 2022 (UTC - 6:00) System Uptime: 0 days 0:00:10.453 Break instruction exception - code 80000003 (first chance) A fatal system error has occurred. Connected to Windows XP 2600 x86 compatible target at (Fri Dec 23 17:36:21.312 2022 (UTC - 6:00)), ptr64 FALSE *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe - Loading Kernel Symbols ............................................................... ........................WARNING: Process directory table base 89840060 doesn't match CR3 00E76000 WARNING: Process directory table base 89840060 doesn't match CR3 00E76000 ........... Loading User Symbols ........ Loading unloaded module list ......... ************* Symbol Loading Error Summary ************** Module name Error ntkrpamp The system cannot find the file specified You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded. You should also verify that your symbol search path (.sympath) is correct. ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 1000007F, {8, 80042000, 0, 0} ***** Kernel symbols are WRONG. Please fix symbols to do analysis. *** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* Probably caused by : ntkrpamp.exe ( nt!KeRegisterBugCheckReasonCallback+c7d ) Followup: MachineOwner --------- nt!DbgBreakPointWithStatus+0x4: 8052b5dc cc int 3 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes: If kv shows a taskGate use .tss on the part before the colon, then kv. Else if kv shows a trapframe use .trap on that value Else .trap on the appropriate frame will show where the trap was taken (on x86, this will be the ebp that goes with the procedure KiTrap) Endif kb will then show the corrected stack. Arguments: Arg1: 00000008, EXCEPTION_DOUBLE_FAULT Arg2: 80042000 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------ ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ADDITIONAL_DEBUG_TEXT: You can run '.symfix; .reload' to try to fix the symbol path and load symbols. MODULE_NAME: nt FAULTING_MODULE: 804d7000 nt DEBUG_FLR_IMAGE_TIMESTAMP: 4802516a BUGCHECK_STR: 0x7f_8 DEFAULT_BUCKET_ID: DRIVER_FAULT ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre LAST_CONTROL_TRANSFER: from 804f9ee5 to 8052b5dc STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 8054e2fc 804f9ee5 00000004 00000000 00000000 nt!DbgBreakPointWithStatus+0x4 8054e6dc 80543551 0000007f 00000008 80042000 nt!KeRegisterBugCheckReasonCallback+0xc7d 00000000 f000eef3 f000e2c3 f0000000 f000eef3 nt!Kei386EoiHelper+0x16a5 00000000 00000000 f000e2c3 f0000000 f000eef3 0xf000eef3 STACK_COMMAND: kb FOLLOWUP_IP: nt!KeRegisterBugCheckReasonCallback+c7d 804f9ee5 8b4dfc mov ecx,dword ptr [ebp-4] SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!KeRegisterBugCheckReasonCallback+c7d FOLLOWUP_NAME: MachineOwner IMAGE_NAME: ntkrpamp.exe IMAGE_VERSION: 5.1.2600.5512 BUCKET_ID: WRONG_SYMBOLS FAILURE_BUCKET_ID: WRONG_SYMBOLS ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:wrong_symbols FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8} Followup: MachineOwner --------- 0: kd> lmvm nt start end module name 804d7000 806e4000 nt (export symbols) ntkrpamp.exe Loaded symbol image file: ntkrpamp.exe Image path: ntkrpamp.exe Image name: ntkrpamp.exe Timestamp: Sun Apr 13 13:31:06 2008 (4802516A) CheckSum: 001F3F78 ImageSize: 0020D000 File version: 5.1.2600.5512 Product version: 5.1.2600.5512 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 1.0 App File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: ntkrpamp.exe OriginalFilename: ntkrpamp.exe ProductVersion: 5.1.2600.5512 FileVersion: 5.1.2600.5512 (xpsp.080413-2111) FileDescription: NT Kernel & System LegalCopyright: © Microsoft Corporation. All rights reserved. Closing open log file L:\test2.txt
Dietmar Posted December 23, 2022 Posted December 23, 2022 @Andalu I would set up everything with windbg brandnew Dietmar
Andalu Posted December 23, 2022 Posted December 23, 2022 (edited) @Dietmar to avoid any problems, I had already installed XP - IE and configured both Host and Target systems from scratch, but evidently it did not help. The log above comes from them. Once again in the log there is the line: "Product: WinNt, suite: TerminalServer SingleUserTS" Edited December 23, 2022 by Andalu
Mov AX, 0xDEAD Posted December 24, 2022 Author Posted December 24, 2022 (edited) 13 hours ago, Andalu said: @Dietmar thanks for the tips. Unfortunately, I cannot overcome the error "Symbol file could not be found" related to ntkrpamp.exe. I copied it together with ntkrpamp.pdb to any directory but the error is still there. @Andalu On HOST pc run "process monitor/file monitor" from SysInternals , look where windbg try to find .pdb for ntkrpamp.exe Edited December 24, 2022 by Mov AX, 0xDEAD
Dietmar Posted December 24, 2022 Posted December 24, 2022 (edited) @Andalu I just test the idea from @Mov AX, 0xDEAD for to find the path, where windbg is looking for ntkrpamp. For this, I run a windbg session with Host and Guest via Lan and stop at the first breakpoint. The last version of Process Monitor, that runs under XP is 3.61 Dietmar Edited December 24, 2022 by Dietmar
Dietmar Posted December 24, 2022 Posted December 24, 2022 (edited) @Andalu May be, that you have installed a wrong version for the Symbols. Then, ntkrpamp of course will never been found. You can use both, free and debug Symbols, in different folders. XP SP3 takes then always the correct one. I think, I am right. You use the free Symbols as I can see at your log. But you need the Debug Symbols. "Windows XP Kernel Version 2600 (Service Pack 3) MP (4 procs) Free x86 compatible" Dietmar Here are my working Symbols for ntos3.exe https://ufile.io/fu5zpo53 Edited December 24, 2022 by Dietmar
Dietmar Posted December 24, 2022 Posted December 24, 2022 @Andalu And here are all the needed files for DEBUG via an Realtek Lan-card Dietmar https://ufile.io/jcyqmz5p
Andalu Posted December 24, 2022 Posted December 24, 2022 (edited) @Mov AX, 0xDEAD @Dietmar thank you for the very useful tips and uploaded files. Unfortunately, the error doesn't want to go away even though ntkrpamp.pdb is correctly in the expected directory: I assume that this error may depend on the different versions of the ntkrpamp.exe and ntkrpamp.pdb files that are present on the Host and Target. However, I have only one ntkrpamp.pdb with SHA-1 0E36280FAD94784C7457E1D05A38E53CB40904D1 linked to ntkrpamp.exe v5.1.2600.7581 (SHA-1 14A56010EDEAED3B171CC9B836BF274DD26D0995). Edited December 24, 2022 by Andalu
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now