I need to replace BOOT-START modules at boot-time,I guess for that i need to change the NT kernel of debug version in windows OS 2012 r2 by kdfiles replacement .
so, I am trying to replace ntkrnlmp.exe debug version in windows 2012 r2 which is provided in WDK 8 .
I am unable to find the path of ntkrnlmp.exe in installed os(System Reserved) and as well as in windows image…
Please help me out how to replace ntknrlmp.exe for windows 2012 r2.
or
Is there any other way to replace BOOT-START modules through .kdfiles.
Please refer replacing boot start drivers link mentioned below:
Setup program will rename kernel file to a unified name like ntoskrnl.exe (right click and look at original file name in Details). BUT you will lose the windows if you only replace the kernel file itself. HAL should be replaced too. (see https://msdn.microsoft.com/en-us/library/windows/hardware/ff547188(v=vs.85).aspx )
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, June 01, 2015 4:07 PM
To: Kernel Debugging Interest List
Subject: [windbg] Replacing Boot Start Drivers and NT kernel debug version for Windows 2012 r2
Hi,
I need to replace BOOT-START modules at boot-time,I guess for that i need to change the NT kernel of debug version in windows OS 2012 r2 by kdfiles replacement .
so, I am trying to replace ntkrnlmp.exe debug version in windows 2012 r2 which is provided in WDK 8 .
I am unable to find the path of ntkrnlmp.exe in installed os(System Reserved) and as well as in windows image…
Please help me out how to replace ntknrlmp.exe for windows 2012 r2.
or
Is there any other way to replace BOOT-START modules through .kdfiles.
Please refer replacing boot start drivers link mentioned below:
The advice in the article you cite is out of date, at least in respect to anything later than Windows XP.
You don’t need to replace the Ntldr, the kernel or HAL at all to debug boot start drivers.
You just need to make sure that, in addition to your usual debug settings, a) you set boot debugging on in bcdedit:
bcdedit /bootdebug on
or possibly
bcdedit /bootdbug {bootmgr} on
and b) ensure that windbg knows to ask for the initial break (windbg -b or -d).
Make sure that any .kdfiles mapping (for your driver, not the kernel) is active before proceeding from the initial break.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-583879- xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: 01 June 2015 09:07
To: Kernel Debugging Interest List
Subject: [windbg] Replacing Boot Start Drivers and NT kernel debug
version for Windows 2012 r2
Hi,
I need to replace BOOT-START modules at boot-time,I guess for that i
need to change the NT kernel of debug version in windows OS 2012 r2 by
kdfiles replacement .
so, I am trying to replace ntkrnlmp.exe debug version in windows 2012
r2 which is provided in WDK 8 .
I am unable to find the path of ntkrnlmp.exe in installed os(System
Reserved) and as well as in windows image…
Please help me out how to replace ntknrlmp.exe for windows 2012 r2.
or
Is there any other way to replace BOOT-START modules through .kdfiles.
Please refer replacing boot start drivers link mentioned below:
with referene to the link you provided i gave a try to make the boot-debug settings described.As result my machine drives to crash, please find the setting details below:
downloaded wdk 8.1 copied ntkrnl.exe and hal.dll to %SYSTEMROOT%/system32/ntkrnl.chk and %SYSTEMROOT%/system32/hal.chk
3.bcdedit /set {44a942bf-d6ee-11e3-baf8-000ffee4f6cd} hal hal.chk
4.bcdedit /bootdebug {44a942bf-d6ee-11e3-baf8-000ffee4f6cd} on
reboot and os getting crashed.
i have a confusion, my machine is multiprocessor so it should have ntkrnlmp.exe in %SYSTEMROOT%/system32/ but it has ntoskrnl.exe and i couldn’t find ntkrnl.exe.
Please let me know if i am making any mistakes.My goal is to get debug version nt kernel binary to be executed and replace modifed boot start drivers by .kdfiles.
I gave multiple tries to replace kdfiles by setting bcdedit /bootdebug on and bcdedit /bootdbug {bootmgr} on , in result i couldn’t replace the kdfiles and none of the logs are displayed in the debugger machine.
please help me if there is any other way to debug boot-start drivers.
with referene to the link you provided i gave a try to make the boot-debug settings described.As result my machine drives to crash, please find the setting details below:
downloaded wdk 8.1 copied ntkrnl.exe and hal.dll to %SYSTEMROOT%/system32/ntkrnl.chk and %SYSTEMROOT%/system32/hal.chk
That is is a different name from what you mentioned in item 1. What
leads you to think that it is necessary to replace the kernel and HAL to
get .kdfiles working for boot drivers?
reboot and os getting crashed.
It’s amazing to me when someone reports that their machine crashed, and
they think that’s enough information for a diagnosis. There are
hundreds of crash codes and thousands of causes for those crashes. At
least tell us the bugcheck code number.
i have a confusion, my machine is multiprocessor so it should have ntkrnlmp.exe in %SYSTEMROOT%/system32/ but it has ntoskrnl.exe and i couldn’t find ntkrnl.exe.
The distinction between “multiprocessor” and “non-multiprocessor”
kernels disappeared more than a decade ago. All machines use a
multiprocessor kernel. It happens to be called “ntoskrnl.exe”.
There has never been an “ntkrnl.exe”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Obtaining an initial break point is a necessary first step towards using .kdfiles for a boot driver, but
.kdfiles can fail to work for reasons completely unrelated to the initial break point. Ditto logging.
So: did you get an initial break point successfully? You can find out by reading the output carefully, or by using the ‘lm’ windbg command.
‘lm’ at the initial breakpoint will list only one module (either ntldr.exe or one of the ntosk*.exe, depending on whether it’s -d or -b).
Until you’ve successfully established this, there’s no point in worrying about kdfiles.
If you have achieved this and are still having problems with the kdfiles, please post the *exact* content of the .kdfiles input file or mapping you are trying to use.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-583899- xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: 01 June 2015 15:30
To: Kernel Debugging Interest List
Subject: RE:[windbg] Replacing Boot Start Drivers and NT kernel debug
version for Windows 2012 r2
Hi David,
I gave multiple tries to replace kdfiles by setting bcdedit
/bootdebug on and bcdedit /bootdbug {bootmgr} on , in result i couldn’t
replace the kdfiles and none of the logs are displayed in the debugger
machine.
please help me if there is any other way to debug boot-start drivers.
sorry, there was an typo it’s not ntkrnl.exe it is ntkrnlmp.exe in item 1 and other points .
I downloaded wdk , found ntkrnlmp.exe , hal.dll and replaced as %SYSTEMROOT%/system32/ntkrnlmp.chk and %SYSTEMROOT%/system32/hal.chk
provided boot debug settings as discussed in the previous post.
debugger log is shown below ,
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 9600 x64 target at (Mon Jun 1 06:05:10.407 2015 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Symbol Path validation summary **************
Response Time (ms) Location
OK D:\Symbols
Symbol search path is: D:\Symbols
Executable search path is:
Windows Boot Debugger Kernel Version 9600 UP Free x64
Machine Name:
Primary image base = 0x00000000008eb000 Loaded module list = 0x0000000000aa42d0
System Uptime: not available
winload!DebugService2+0x5:
0000000000a1b4f5 cc int 3 kd\> lm start end module name 00000000008eb000 00000000`00ac0000 winload (pdb symbols) d:\symbols\winload_prod.pdb\E5D38A068D3C452CB428119589C0B12E1\winload_prod.pdb
kd> g
*** Windows is unable to verify the signature of
the file \Windows\system32\ntkrnlmp.chk. It will be allowed to load
because the boot debugger is enabled.
*** Windows is unable to verify the signature of
the file \Windows\system32\hal.chk. It will be allowed to load
because the boot debugger is enabled.
Shutdown occurred at (Mon Jun 1 06:05:46.985 2015 (UTC - 7:00))…unloading all symbol tables.
Waiting to reconnect…
Please let me know if i can provide any additional information.
I have tried giving proper initial break, by ctrl+alt+k this breaks kernel initially at next boot.
given lm followed by -d or -b i can see only winload.exe module
next I release the kernel and refresh my kdfiles by passing .kdfiles <path_to_my_kdfile.ini>
ini file details are mentioned below: map \systemroot\system32\drivers\mydriver.sys D:\project\mydriver.sys
as result i still unable to refresh my boot start driver.
If by ‘I release the kernel’ you mean that you are letting the boot continue before executing the .kdfiles command, then that’s a problem - you must establish the .kdfiles mapping before any boot driver module. Run .kdfiles at the first break.
Another reason why your kdfiles command might not be working is that the second line (beginning \systemroot.…) has to match what’s in the service Control manager database (case-insensitively). Sometimes a system needs \systemroot\ and sometimes not.
I’ve never worked out how to find the correct form deterministically - I often have to try both.
Also, I recommend *always* running a .kdfiles command with no arguments after your .kdfiles <path_to_my_kdfile.ini> to check that the command has worked.
> -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-583983- > xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com > Sent: 02 June 2015 15:11 > To: Kernel Debugging Interest List > Subject: RE:[windbg] Replacing Boot Start Drivers and NT kernel debug > version for Windows 2012 r2 > > > Hi David, > > Thanks for showing support. > > I have tried giving proper initial break, by ctrl+alt+k this breaks > kernel initially at next boot. > given lm followed by -d or -b i can see only winload.exe module > > next I release the kernel and refresh my kdfiles by passing .kdfiles > <path_to_my_kdfile.ini> > > ini file details are mentioned below: > map > \systemroot\system32\drivers\mydriver.sys > D:\project\mydriver.sys > > as result i still unable to refresh my boot start driver. > > please let me know if any steps are left behind. > > Thanks, > > Luis This email message has been delivered safely and archived online by Mimecast.
For more information please visit http://www.mimecast.com</path_to_my_kdfile.ini></path_to_my_kdfile.ini>
By Making changes in .ini file , .kdfiles are loading at boot time .
i.e
map
system32\drivers\mydriver.sys
D:\project\mydriver.sys
It would be really helpful to me if i get a solution to replace Nt kernel into debug version.
By Replacing Nt Kernel debug version i could collect detailed logs of NT kernel and make sure if windows kernel is getting BSOD due to mydrivrer.sys which is an BOOT_START_DRIVER.
It would be really helpful to me if i get a solution to replace Nt
kernel into debug version.
By Replacing Nt Kernel debug version i could collect detailed logs of
NT kernel and make sure if windows kernel is getting BSOD due to
mydrivrer.sys which is an BOOT_START_DRIVER.
please let me know if anyone could help.
Thanks,
Luis
I’ve never attempted to replace the kernel with a debug version (I haven’t had the need to), so I’m at the end of my experience on this.
What I can do is suggest that you adopt an alternative approach - use the driver verifier to check your driver.
can i use ntkrnl.exe and hal.dll available in wdk 8.1? or is there any way to obtain debug version binaries for windows 2012 r2 kernel.
please let me know .
Do you mean to say, you have checked copying wdk 8.1 binaries in %SYSTEMROOT%\System32 location? and debugged the kernel?
i have made multiple tries copying ntkrnlmp.exe and hal.dll in the root location(%SYSTEMROOT%\System32) , this is not helping me out. please find the debug details below :
---------------------------------------------------------------------------------------------- BD: Boot Debugger Initialized Connected to Windows Boot Debugger 9600 x64 target at (Mon Jun 1 01:01:26.532 2015 (UTC - 7:00)), ptr64 TRUE Kernel Debugger connection established.
Symbol Path validation summary* Response Time (ms) Location OK D:\Symbols OK D:\MLNX_4.2\SymbWinOF4_2\x64 Symbol search path is: D:\Symbols;D:\MLNX_4.2\SymbWinOF4_2\x64 Executable search path is: Windows Boot Debugger Kernel Version 9600 UP Free x64 Machine Name: Primary image base = 0x00000000008eb000 Loaded module list = 0x0000000000aa42d0 System Uptime: not available winload!DebugService2+0x5: 0000000000a1b4f5 cc int 3<br>kd> g<br>***Windows is unable to verify the signature of<br> the file \Windows\System32\drivers\mlx4_bus.sys. It will be allowed to load<br> because the boot debugger is enabled.<br>Shutdown occurred at (Mon Jun 1 01:01:37.204 2015 (UTC - 7:00))...unloading all symbol tables.<br>Waiting to reconnect...<br>Connected to Windows 8 9600 x64 target at (Mon Jun 1 01:01:38.063 2015 (UTC - 7:00)), ptr64 TRUE<br>Kernel Debugger connection established.<br><br>************* Symbol Path validation summary **************<br>Response Time (ms) Location<br>OK D:\Symbols<br>OK D:\MLNX_4.2\SymbWinOF4_2\x64<br>Symbol search path is: D:\Symbols;D:\MLNX_4.2\SymbWinOF4_2\x64<br>Executable search path is: <br>Windows 8 Kernel Version 9600 MP (1 procs) Free x64<br>Built by: 9600.16384.amd64fre.winblue_rtm.130821-1623<br>Machine Name:<br>Kernel base = 0xfffff8024a40e000 PsLoadedModuleList = 0xfffff8024a6d59b0<br>System Uptime: 0 days 0:00:00.051<br>nt!DebugService2+0x5:<br>fffff8024a564ce5 cc int 3 kd> g IOINIT: Built-in driver \Driver\sacdrv failed to initialize with status - 0xC0000037 KDTARGET: Refreshing KD connection Break instruction exception - code 80000003 (first chance) You are seeing this message because you pressed either CTRL+C (if you run console kernel debugger) or, CTRL+BREAK (if you run GUI kernel debugger), on your debugger machine’s keyboard. THIS IS NOT A BUG OR A SYSTEM CRASH If you did not intend to break into the debugger, press the “g” key, then press the “Enter” key now. This message might immediately reappear. If it does, press “g” and “Enter” again.
nt!DbgBreakPointWithStatus: fffff8024a564c90 cc int 3<br>0: kd> lm v mnt<br>start end module name<br>fffff8024a40e000 fffff8024ab91000 nt (pdb symbols) d:\symbols\ntkrnlmp.pdb\A9BBA3C139724A738BE17665DB4393CA1\ntkrnlmp.pdb<br> Loaded symbol image file: ntkrnlmp.exe<br> Image path: ntkrnlmp.exe<br> Image name: ntkrnlmp.exe<br> Timestamp: Thu Aug 22 01:52:38 2013 (5215D156)<br> CheckSum: 00716313<br> ImageSize: 00783000<br> File version: 6.3.9600.16384<br> Product version: 6.3.9600.16384<br> File flags: 0 (Mask 3F)<br> File OS: 40004 NT Win32<br> File type: 1.0 App<br> File date: 00000000.00000000<br> Translations: 0409.04b0<br> CompanyName: Microsoft Corporation<br> ProductName: Microsoft? Windows? Operating System<br> InternalName: ntkrnlmp.exe<br> OriginalFilename: ntkrnlmp.exe<br> ProductVersion: 6.3.9600.16384<br> FileVersion: 6.3.9600.16384 (winblue_rtm.130821-1623)<br> FileDescription: NT Kernel & System<br> LegalCopyright: ? Microsoft Corporation. All rights reserved.<br><br>Unable to enumerate user-mode unloaded modules, Win32 error 0n30<br>0: kd> g<br>WER/CrashAPI:1959: ERROR ReadProcessMemory failed while trying to read PebBaseAddress<br>WER/CrashAPI:2068: ERROR Failed to read the peb from the process<br>WER/CrashAPI:1959: ERROR ReadProcessMemory failed while trying to read PebBaseAddress<br>WER/CrashAPI:2068: ERROR Failed to read the peb from the process<br>WER/CrashAPI:1959: ERROR ReadProcessMemory failed while trying to read PebBaseAddress<br>WER/CrashAPI:2068: ERROR Failed to read the peb from the process<br>WER/CrashAPI:1959: ERROR ReadProcessMemory failed while trying to read PebBaseAddress<br>BD: Boot Debugger Initialized<br>*** Windows is unable to verify the signature of<br> the file \Windows\system32\ntkrnlmp.chk. It will be allowed to load<br> because the boot debugger is enabled.<br>***Windows is unable to verify the signature of<br> the file \Windows\system32\hal.chk. It will be allowed to load<br> because the boot debugger is enabled.<br>Shutdown occurred at (Mon Jun 1 05:58:36.422 2015 (UTC - 7:00))...unloading all symbol tables.<br>Waiting to reconnect...<br>Connected to Windows 8 9600 x64 target at (Mon Jun 1 05:58:37.297 2015 (UTC - 7:00)), ptr64 TRUE<br>Kernel Debugger connection established.<br><br>************* Symbol Path validation summary **************<br>Response Time (ms) Location<br>OK D:\Symbols<br>OK D:\MLNX_4.2\SymbWinOF4_2\x64<br>Symbol search path is: D:\Symbols;D:\MLNX_4.2\SymbWinOF4_2\x64<br>Executable search path is: <br>*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe - <br>Windows 8 Kernel Version 9600 MP (1 procs) Checked x64<br>Built by: 9600.17246.amd64chk.winblue_gdr.140801-1518<br>Machine Name:<br>Kernel base = 0xfffff803bba8b000 PsLoadedModuleList = 0xfffff803bc294670<br>System Uptime: 0 days 0:00:00.051 (checked kernels begin at 49 days)<br> ***ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe - <br>nt!DbgBreakPointWithStatus+0x55:<br>fffff803bbd18e55 cc int 3
************* Symbol Path validation summary * Response Time (ms) Location OK D:\Symbols OK D:\MLNX_4.2\SymbWinOF4_2\x64 kd> .reload /f Connected to Windows 8 9600 x64 target at (Mon Jun 1 05:59:46.063 2015 (UTC - 7:00)), ptr64 TRUE ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe - Loading Kernel Symbols .ERROR: Symbol file could not be found. Defaulted to export symbols for hal.chk - …
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols.
… Loading User Symbols
Loading unloaded module list Unable to enumerate kernel-mode unloaded modules, HRESULT 0x80004005 Cannot read PEB32 from WOW64 TEB32 f000ddc8 - NTSTATUS 0xC0000141
Symbol Loading Error Summary * Module name Error ntkrnlmp The system cannot find the file specified hal PDB not found : d:\symbols\symbols\chk\hal.pdb PDB not found : d:\mlnx_4.2\symbwinof4_2\x64\symbols\chk\hal.pdb
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. kd> g Break instruction exception - code 80000003 (first chance) You are seeing this message because you pressed either CTRL+C (if you run console kernel debugger) or, CTRL+BREAK (if you run GUI kernel debugger), on your debugger machine’s keyboard. THIS IS NOT A BUG OR A SYSTEM CRASH If you did not intend to break into the debugger, press the “g” key, then press the “Enter” key now. This message might immediately reappear. If it does, press “g” and “Enter” again.
nt!DbgBreakPointWithStatus: fffff803bbd18e00 cc int 3<br>kd> lm<br>start end module name<br>fffff8016ec00000 fffff8016ec5f000 volmgrx (deferred) <br>fffff8016ec81000 fffff8016ece7000 mcupdate_GenuineIntel (deferred) <br>fffff8016ece7000 fffff8016ecf5000 werkernel (deferred) <br>fffff8016ecf5000 fffff8016ed57000 CLFS (deferred) <br>fffff8016ed57000 fffff8016ed79000 tm (deferred) <br>fffff8016ed79000 fffff8016ed8e000 PSHED (deferred) <br>fffff8016ed8e000 fffff8016ed98000 BOOTVID (deferred) <br>fffff8016ed98000 fffff8016edf5000 spaceport (deferred) <br>fffff8016ee00000 fffff8016ee18000 acpiex (deferred) <br>fffff8016ee18000 fffff8016ee23000 WppRecorder (deferred) <br>fffff8016ee3b000 fffff8016eec3000 CI (deferred) <br>fffff8016eec3000 fffff8016ef20000 msrpc (deferred) <br>fffff8016ef20000 fffff8016efef000 Wdf01000 (deferred) <br>fffff8016efef000 fffff8016f000000 WDFLDR (deferred) <br>fffff8016f000000 fffff8016f08b000 cng (deferred) <br>fffff8016f08b000 fffff8016f0b7000 tpm (deferred) <br>fffff8016f0b7000 fffff8016f0d2000 sacdrv (deferred) <br>fffff8016f0d2000 fffff8016f0e1000 PCIIDEX (deferred) <br>fffff8016f0f5000 fffff8016f17a000 ACPI (deferred) <br>fffff8016f17a000 fffff8016f184000 WMILIB (deferred) <br>fffff8016f184000 fffff8016f18e000 msisadrv (deferred) <br>fffff8016f18e000 fffff8016f1d7000 pci (deferred) <br>fffff8016f200000 fffff8016f215000 volmgr (deferred) <br>fffff8016f215000 fffff8016f21d000 pciide (deferred) <br>fffff8016f221000 fffff8016f339000 NDIS (deferred) <br>fffff8016f339000 fffff8016f3b2000 NETIO (deferred) <br>fffff8016f3b2000 fffff8016f3bf000 vdrvroot (deferred) <br>fffff8016f3bf000 fffff8016f3db000 pdc (deferred) <br>fffff8016f3db000 fffff8016f3f3000 partmgr (deferred) <br>fffff8016f400000 fffff8016f45c000 fltmgr (deferred) <br>fffff8016f47c000 fffff8016f505000 bxvbda (deferred) <br>fffff8016f505000 fffff8016f520000 mountmgr (deferred) <br>fffff8016f520000 fffff8016f52a000 atapi (deferred) <br>fffff8016f52a000 fffff8016f55f000 ataport (deferred) <br>fffff8016f55f000 fffff8016f570000 megasas (deferred) <br>fffff8016f570000 fffff8016f5cf000 storport (deferred) <br>fffff8016f64b000 fffff8016f841000 Ntfs (deferred) <br>fffff8016f841000 fffff8016f85c000 ksecdd (deferred) <br>fffff8016f85c000 fffff8016f86c000 pcw (deferred) <br>fffff8016f86c000 fffff8016f877000 Fs_Rec (deferred) <br>fffff8016f877000 fffff8016f8ab000 ksecpkg (deferred) <br>fffff8016f8ab000 fffff8016f901000 CLASSPNP (deferred) <br>fffff8016fa00000 fffff8016fa50000 volsnap (deferred) <br>fffff8016fa50000 fffff8016fa67000 mup (deferred) <br>fffff8016fa67000 fffff8016fa73000 hwpolicy (deferred) <br>fffff8016fa73000 fffff8016fa8f000 disk (deferred) <br>fffff8016fab7000 fffff8016fd35000 tcpip (deferred) <br>fffff8016fd35000 fffff8016fda1000 fwpkclnt (deferred) <br>fffff8016fda1000 fffff8016fdc6000 wfplwfs (deferred) <br>fffff803bad6a000 fffff803bad75000 kdcom (deferred) <br>fffff803bba1e000 fffff803bba8b000 hal (deferred) <br>fffff803bba8b000 fffff803bc9a3000 nt (export symbols) ntkrnlmp.exe<br>kd> g<br>Assertion failure - code c0000420 (first chance)<br>nt!FsRtlSendModernAppTermination+0xa6:<br>fffff803bbad84aa cd2c int 2Ch 3: kd> g Continuing an assertion failure can result in the debuggee being terminated (bugchecking for kernel debuggees). If you want to ignore this assertion, use ‘ahi’. If you want to force continuation, use ‘gh’ or ‘gn’. 3: kd> ahi nt!FsRtlSendModernAppTermination+0xa6 (fffff803bbad84aa)- ignore<br>3: kd> g<br>Assertion failure - code c0000420 (first chance)<br>nt!psMUITest+0x28115:<br>fffff803bc8e0a25 cd2c int 2Ch 3: kd> gn KDTARGET: Refreshing KD connection
Fatal System Error: 0x0000007e (0xFFFFFFFFC0000420,0xFFFFF803BC8E0A25,0xFFFFD00200FFB8B8,0xFFFFD00200FFAFB0)
A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
Connected to Windows 8 9600 x64 target at (Mon Jun 1 06:02:08.704 2015 (UTC - 7:00)), ptr64 TRUE ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe - Loading Kernel Symbols …
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols.
… Loading User Symbols
Symbol Loading Error Summary ************** Module name Error ntkrnlmp 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.
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
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 : ntkrnlmp.exe ( nt!psMUITest+28115 )
Followup: MachineOwner ---------
nt!DbgBreakPointWithStatus: fffff803bbd18e00 cc int 3<br>3: kd> analyze -v<br>Couldn't resolve error at 'nalyze -v'<br>3: kd> analyze -v<br>Couldn't resolve error at 'nalyze -v'<br>3: kd> !analyze -v<br> *******************************************************************************<br>* *<br>* Bugcheck Analysis *<br>* *<br>******************************************************************************* <br><br>SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)<br>This is a very common bugcheck. Usually the exception address pinpoints<br>the driver/function that caused the problem. Always note this address<br>as well as the link date of the driver/image that contains this address.<br>Arguments:<br>Arg1: ffffffffc0000420, The exception code that was not handled<br>Arg2: fffff803bc8e0a25, The address that the exception occurred at<br>Arg3: ffffd00200ffb8b8, Exception Record Address<br>Arg4: ffffd00200ffafb0, Context Record Address<br><br>Debugging Details:<br>------------------<br><br> *****Kernel symbols are WRONG. Please fix symbols to do analysis.<br><br>************************************************************************* <br> ****** <br> ****** <br> ***Either you specified an unqualified symbol, or your debugger*** <br> ***doesn't have full symbol information. Unqualified symbol*** <br> ***resolution is turned off by default. Please either specify a*** <br> ***fully qualified symbol module!symbolname, or enable resolution*** <br> ***of unqualified symbols by typing ".symopt- 100". Note that*** <br> ***enabling unqualified symbol resolution with network symbol*** <br> ***server shares in the symbol path may cause the debugger to*** <br> ***appear to hang for long periods of time when an incorrect*** <br> ***symbol name is typed or the network symbol server is down.*** <br> ****** <br> ***For some commands to work properly, your symbol path*** <br> ***must point to .pdb files that have full type information.*** <br> ****** <br>***Certain .pdb files (such as the public OS symbols) do not***<br> ***contain the required information. Contact the group that*** <br> ***provided you with these symbols if you need this command to*** <br> ***work.*** <br> ****** <br> ***Type referenced: nt!_KPRCB*** <br> ****** <br> *************************************************************************<br>************************************************************************* <br> ****** <br> ****** <br> ***Either you specified an unqualified symbol, or your debugger*** <br> ***doesn't have full symbol information. Unqualified symbol*** <br> ***resolution is turned off by default. Please either specify a*** <br> ***fully qualified symbol module!symbolname, or enable resolution*** <br> ***of unqualified symbols by typing ".symopt- 100". Note that*** <br> ***enabling unqualified symbol resolution with network symbol*** <br> ***server shares in the symbol path may cause the debugger to*** <br> ***appear to hang for long periods of time when an incorrect*** <br> ***symbol name is typed or the network symbol server is down.*** <br> ****** <br> ***For some commands to work properly, your symbol path*** <br> ***must point to .pdb files that have full type information.*** <br> ****** <br>***Certain .pdb files (such as the public OS symbols) do not***<br> ***contain the required information. Contact the group that*** <br> ***provided you with these symbols if you need this command to*** <br> ***work.*** <br> ****** <br> ***Type referenced: nt!_KPRCB*** <br> ****** <br> *************************************************************************<br>************************************************************************* <br> ****** <br> ****** <br> ***Either you specified an unqualified symbol, or your debugger*** <br> ***doesn't have full symbol information. Unqualified symbol*** <br> ***resolution is turned off by default. Please either specify a*** <br> ***fully qualified symbol module!symbolname, or enable resolution*** <br> ***of unqualified symbols by typing ".symopt- 100". Note that*** <br> ***enabling unqualified symbol resolution with network symbol*** <br> ***server shares in the symbol path may cause the debugger to*** <br> ***appear to hang for long periods of time when an incorrect*** <br> ***symbol name is typed or the network symbol server is down.*** <br> ****** <br> ***For some commands to work properly, your symbol path*** <br> ***must point to .pdb files that have full type information.*** <br> ****** <br>***Certain .pdb files (such as the public OS symbols) do not***<br> ***contain the required information. Contact the group that*** <br> ***provided you with these symbols if you need this command to*** <br> ***work.*** <br> ****** <br> ***Type referenced: nt!_KPRCB*** <br> ****** <br>*************************************************************************<br><br>ADDITIONAL_DEBUG_TEXT: <br>You can run '.symfix; .reload' to try to fix the symbol path and load symbols.<br><br>MODULE_NAME: nt<br><br>FAULTING_MODULE: fffff803bba8b000 nt<br><br>DEBUG_FLR_IMAGE_TIMESTAMP: 53dc4d4f<br><br>EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.<br><br>FAULTING_IP: <br>nt!psMUITest+28115<br>fffff803bc8e0a25 cd2c int 2Ch
FOLLOWUP_IP: nt!psMUITest+28115 fffff803bc8e0a25 cd2c int 2Ch<br><br>SYMBOL_STACK_INDEX: 0<br><br>SYMBOL_NAME: nt!psMUITest+28115<br><br>FOLLOWUP_NAME: MachineOwner<br><br>IMAGE_NAME: ntkrnlmp.exe<br><br>IMAGE_VERSION: 6.3.9600.17246<br><br>STACK_COMMAND: .cxr 0xffffd00200ffafb0 ; kb<br><br>BUCKET_ID: WRONG_SYMBOLS<br><br>FAILURE_BUCKET_ID: WRONG_SYMBOLS<br><br>ANALYSIS_SOURCE: KM<br><br>FAILURE_ID_HASH_STRING: km:wrong_symbols<br><br>FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8}<br><br>Followup: MachineOwner<br>---------<br><br>3: kd> g<br>Shutdown occurred at (Mon Jun 1 06:04:04.610 2015 (UTC - 7:00))...unloading all symbol tables.<br>Waiting to reconnect...<br>BD: Boot Debugger Initialized<br>Connected to Windows Boot Debugger 9600 x64 target at (Mon Jun 1 06:05:10.407 2015 (UTC - 7:00)), ptr64 TRUE<br>Kernel Debugger connection established.<br><br>************* Symbol Path validation summary **************<br>Response Time (ms) Location<br>OK D:\Symbols<br>OK D:\MLNX_4.2\SymbWinOF4_2\x64<br>Symbol search path is: D:\Symbols;D:\MLNX_4.2\SymbWinOF4_2\x64<br>Executable search path is: <br>Windows Boot Debugger Kernel Version 9600 UP Free x64<br>Machine Name:<br>Primary image base = 0x00000000008eb000 Loaded module list = 0x0000000000aa42d0<br>System Uptime: not available<br>winload!DebugService2+0x5:<br>0000000000a1b4f5 cc int 3 kd> lm start end module name 00000000008eb000 0000000000ac0000 winload (pdb symbols) d:\symbols\winload_prod.pdb\E5D38A068D3C452CB428119589C0B12E1\winload_prod.pdb kd> g Windows is unable to verify the signature of the file \Windows\system32\ntkrnlmp.chk. It will be allowed to load because the boot debugger is enabled. Windows is unable to verify the signature of the file \Windows\system32\hal.chk. It will be allowed to load because the boot debugger is enabled. Shutdown occurred at (Mon Jun 1 06:05:46.985 2015 (UTC - 7:00))…unloading all symbol tables. Waiting to reconnect… Connected to Windows 8 9600 x64 target at (Mon Jun 1 06:05:47.844 2015 (UTC - 7:00)), ptr64 TRUE Kernel Debugger connection established.
Symbol Path validation summary *********** Response Time (ms) Location OK D:\Symbols OK D:\MLNX_4.2\SymbWinOF4_2\x64 Symbol search path is: D:\Symbols;D:\MLNX_4.2\SymbWinOF4_2\x64 Executable search path is: ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe - Windows 8 Kernel Version 9600 MP (1 procs) Checked x64 Built by: 9600.17246.amd64chk.winblue_gdr.140801-1518 Machine Name: Kernel base = 0xfffff802ab684000 PsLoadedModuleList = 0xfffff802abe8d670 System Uptime: 0 days 0:00:00.051 (checked kernels begin at 49 days) ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe - nt!DbgBreakPointWithStatus+0x55: fffff802ab911e55 cc int 3<br>kd> lm<br>start end module name<br>fffff802ab684000 fffff802ac59c000 nt (export symbols) ntkrnlmp.exe<br><br>Unable to enumerate kernel-mode unloaded modules, HRESULT 0x80004005<br>kd> g<br>Assertion failure - code c0000420 (first chance)<br>nt!FsRtlSendModernAppTermination+0xa6:<br>fffff802ab6d14aa cd2c int 2Ch 3: kd> !analysis -v No export analysis found 3: kd> g Continuing an assertion failure can result in the debuggee being terminated (bugchecking for kernel debuggees). If you want to ignore this assertion, use ‘ahi’. If you want to force continuation, use ‘gh’ or ‘gn’. 3: kd> gn KDTARGET: Refreshing KD connection
Fatal System Error: 0x0000007e (0xFFFFFFFFC0000420,0xFFFFF802AB6D14AA,0xFFFFD000243FB848,0xFFFFD000243FAF40)
A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
nt!DbgBreakPointWithStatus: fffff802`ab911e00 cc int 3 3: kd> !analysis -v No export analysis found 3: kd> g Shutdown occurred at (Mon Jun 1 06:10:58.516 2015 (UTC - 7:00))…unloading all symbol tables. Waiting to reconnect… -----------------------------------------------------------------------------------------------
please let me know is there any possibility to change windows into debug version or can i purchase checked build windows 2012 r2 .
No. What I mean is that for the past 20+ years, simultaneous server/client releases have had identical binaries. But I have NOT verified that the 8.1 binaries are identical to S12R2, however I would expect that this is, in fact, the case, as it has been in the past. Of course, it’s rather straight-forward to check.
So, to confirm that this is still true, I just looked at the files on the distribution ISO images:
From the Server 2012R2 ISO image:
08/22/2013 06:25 AM 7,416,160 ntoskrnl.exe
From the Windows 8.1 ISO image:
08/22/2013 06:25 AM 7,416,160 ntoskrnl.exe
That’s about as identical as these files can get.
So, once again, the reason there’s only a single debug release is because there’s only one binary, albeit in different configurations. Thus, I can now say “yes, I’ve checked the 8.1 binaries for windows kernel for client and server systems and they are IDENTICAL”.
It’s a bit more complicated getting just the checked kernel/hal than it used to be: you need to install the ADK and use the “imagex” utility (using the “/mount” option) from that to extract the “install.wim” package from the ISO image for the debug/checked distribution kit. Once you’ve done that, you can just grab the ntoskrnl.exe and hal.dll image from the location where you unpacked it.
In my case, I copied ntoskrnl.exe to ntoskrnl.chk and hal.dll to hal.chk to the %systemroot%\system32 directory on the target system. Note that this is the ONLY place where you can put these files.
Then I used bcdedit, first to make a copy of the current boot line (“bcdedit /copy …”) and then I grabbed the GUID for the new entry and set the options (“bcdedit /set kernel ntoskrnl.chk” and then “bcdedit /set hal hal.chk”).
When I rebooted, I saw the proof in the debugger:
Connected to Windows 8 9600 x64 target at (Thu Jun 11 14:19:21.724 2015 (UTC - 7:00)), ptr64 TRUE Kernel Debugger connection established.
Symbol Path validation summary* Response Time (ms) Location Deferred srvd:\symbols\websymbolshttp://msdl.microsoft.com/download/symbols Symbol search path is: srvd:\symbols\websymbolshttp://msdl.microsoft.com/download/symbols Executable search path is: Windows 8 Kernel Version 9600 MP (1 procs) Checked x64 Built by: 9600.16384.amd64chk.winblue_rtm.130821-1623 Machine Name: Kernel base = 0xfffff802ffc81000 PsLoadedModuleList = 0xfffff80300486230 System Uptime: 0 days 0:00:00.103 (checked kernels begin at 49 days)