> HI folks, > > I’ve a problem with local KD on Win 7 64 bit running on a notebook (Sandy > Bridge dual core/4GB ram) > > Installation of Debugging Tools x64 from SDK 7.1 goes fine and then I’ve > activated kernel debugging using bcdedit -debug on from cmd > > Now at reboot the system freezes and there is no way to log into…to > recover just restart in safe mode deactivating debug flag… > > Help !!! > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
local KD aka lkd aka local kernel debugging aka live local debugging aka
c:\> windbg -kl
does not require two computers
carlo i faintly remember going through crashes in x32 too in win7 vms
and reading in latest docs somewhere that lkd doesnt requre /debug
switch
try doing kd -kl or windbg -kl without /debug switch
On 6/18/13, Danny wrote: > You need 2 computers to do KD in windows: host + target. > Have you read > http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v=vs.85).aspx > ? > > > 2013/6/18 > >> HI folks, >> >> I’ve a problem with local KD on Win 7 64 bit running on a notebook (Sandy >> Bridge dual core/4GB ram) >> >> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then I’ve >> activated kernel debugging using bcdedit -debug on from cmd >> >> Now at reboot the system freezes and there is no way to log into…to >> recover just restart in safe mode deactivating debug flag… >> >> Help !!! >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > > > – > Danny > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
Local KD does require /debug (since Vista I believe). The system freeze is most likely caused by something like breakpoint in a user process which gets trapped by kernel debugger. On win8 the best way to use local kd is to set debugger transport to “local” (bcdedit /set dbgsettings local). This will prevent the system from trying to break into debugger and hanging.
On win7 you can try disabling breaks on user mode exceptions (bcdedit /set noumex on).
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Tuesday, June 18, 2013 3:56 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] local KD Win 7 64 bit - system freeze
local KD aka lkd aka local kernel debugging aka live local debugging aka c:\> windbg -kl does not require two computers
carlo i faintly remember going through crashes in x32 too in win7 vms and reading in latest docs somewhere that lkd doesnt requre /debug switch
try doing kd -kl or windbg -kl without /debug switch
On 6/18/13, Danny wrote: > You need 2 computers to do KD in windows: host + target. > Have you read > http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v=vs > .85).aspx > ? > > > 2013/6/18 > >> HI folks, >> >> I’ve a problem with local KD on Win 7 64 bit running on a notebook >> (Sandy Bridge dual core/4GB ram) >> >> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >> I’ve activated kernel debugging using bcdedit -debug on from cmd >> >> Now at reboot the system freezes and there is no way to log into…to >> recover just restart in safe mode deactivating debug flag… >> >> Help !!!
I didn’t see the original message, but debugging a driver on other than a
“disposable” machine is extremely risky. Traditionally, this was a second
computer, but these days the trend is to use a virtual machine. Just be
aware that if you are debugging a driver that is running on your laptop,
you may see it become unbootable, or bootable with serious file system
corruption (I’ve seen both). Be prepared for the experience that after
any run of your experimental driver, you might lose everything on that
machine. That’s why a VM is used: you clone your target VM, and debug in
the clone. Any damage occurs, you can trivially re-clone your VM.
Then again, maybe you like juggling bowling balls while standing on thin
ice, or juggling flaming torches while covered in flammable liquid. Local
debugging is not for the faint of heart.
joe
Local KD does require /debug (since Vista I believe). The system freeze is
most likely caused by something like breakpoint in a user process which
gets trapped by kernel debugger. On win8 the best way to use local kd is
to set debugger transport to “local” (bcdedit /set dbgsettings local).
This will prevent the system from trying to break into debugger and
hanging.
On win7 you can try disabling breaks on user mode exceptions (bcdedit /set
noumex on).
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Tuesday, June 18, 2013 3:56 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] local KD Win 7 64 bit - system freeze
local KD aka lkd aka local kernel debugging aka live local debugging aka
c:\> windbg -kl does not require two computers
carlo i faintly remember going through crashes in x32 too in win7 vms and
reading in latest docs somewhere that lkd doesnt requre /debug switch
try doing kd -kl or windbg -kl without /debug switch
On 6/18/13, Danny wrote: >> You need 2 computers to do KD in windows: host + target. >> Have you read >> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v=vs >> .85).aspx >> ? >> >> >> 2013/6/18 >> >>> HI folks, >>> >>> I’ve a problem with local KD on Win 7 64 bit running on a notebook >>> (Sandy Bridge dual core/4GB ram) >>> >>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >>> I’ve activated kernel debugging using bcdedit -debug on from cmd >>> >>> Now at reboot the system freezes and there is no way to log into…to >>> recover just restart in safe mode deactivating debug flag… >>> >>> Help !!! > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
@newcomer
sorry you are way off the mark local debugging is nothing but
analyzing a crash dump and event the faintest of the heart can do it
a snap shot of the state of machine is taken and windbg is led to
believe that it is looking at a crash dump is what is called local kd
(you cannot step / run / break / view registers and / or corrupt
anything except viewing some kernel mode data )
On 6/19/13, xxxxx@flounder.com wrote: > I didn’t see the original message, but debugging a driver on other than a > “disposable” machine is extremely risky. Traditionally, this was a second > computer, but these days the trend is to use a virtual machine. Just be > aware that if you are debugging a driver that is running on your laptop, > you may see it become unbootable, or bootable with serious file system > corruption (I’ve seen both). Be prepared for the experience that after > any run of your experimental driver, you might lose everything on that > machine. That’s why a VM is used: you clone your target VM, and debug in > the clone. Any damage occurs, you can trivially re-clone your VM. > > Then again, maybe you like juggling bowling balls while standing on thin > ice, or juggling flaming torches while covered in flammable liquid. Local > debugging is not for the faint of heart. > joe > >> Local KD does require /debug (since Vista I believe). The system freeze >> is >> most likely caused by something like breakpoint in a user process which >> gets trapped by kernel debugger. On win8 the best way to use local kd is >> to set debugger transport to “local” (bcdedit /set dbgsettings local). >> This will prevent the system from trying to break into debugger and >> hanging. >> >> On win7 you can try disabling breaks on user mode exceptions (bcdedit >> /set >> noumex on). >> >> -----Original Message----- >> From: xxxxx@lists.osr.com >> [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r >> Sent: Tuesday, June 18, 2013 3:56 AM >> To: Kernel Debugging Interest List >> Subject: Re: [windbg] local KD Win 7 64 bit - system freeze >> >> local KD aka lkd aka local kernel debugging aka live local debugging aka >> c:> windbg -kl does not require two computers >> >> carlo i faintly remember going through crashes in x32 too in win7 vms and >> reading in latest docs somewhere that lkd doesnt requre /debug switch >> >> try doing kd -kl or windbg -kl without /debug switch >> >> On 6/18/13, Danny wrote: >>> You need 2 computers to do KD in windows: host + target. >>> Have you read >>> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v=vs >>> .85).aspx >>> ? >>> >>> >>> 2013/6/18 >>> >>>> HI folks, >>>> >>>> I’ve a problem with local KD on Win 7 64 bit running on a notebook >>>> (Sandy Bridge dual core/4GB ram) >>>> >>>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >>>> I’ve activated kernel debugging using bcdedit -debug on from cmd >>>> >>>> Now at reboot the system freezes and there is no way to log into…to >>>> recover just restart in safe mode deactivating debug flag… >>>> >>>> Help !!! >> >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
I have always had trouble with local kernel debugging with just the native OS support. XP works OK but it does need the -debug. Since Vista I have never been able to make it running.
Go to Sysinternals and get LiveKD. Setup the symbol path and do LiveKD -w. It usually just works, on 32 or 64-bit windows.
Note that it is best to setup the symbol path before you run LiveKD.exe, it needs it for determining which part of the memory is where.
@raj_r
Joseph Newcomer way off the mark? I doubt it. The point Joe was making, which you so blithely ignored, was that debugging ANY kernel driver on a critical system, in this case your one and only laptop with all your business, family photos, and development files on it, is HIGHLY ill-advised because that kernel driver can EASILY hose your system. It doesn’t matter if your the single most brilliant crash dump reader in the world, if your driver craps out in the wrong place at the wrong time you can very possibly end up writing random data to the boot system in a random order that cause you to loose ALL of the data, OS and anything else on your storage media. When debugging ANY kernel driver you MUST sandbox the system, either by using a second system or running the driver in a VM on you critical system.
Analyzing crash dumps are indeed an important tool, and opening them in WinDbg makes it a googolplex easier than some of the dump analysis we were doing in the 70’s and 80’s: e.g. a binary dump of hundreds of thousand bytes,a linkage edit map, and a box of colored highlighters. A crash-dump sitting on a critical system that will no longer boot to in any mode is worthless. Oh you say, just mount the drive in an external enclosure. In 40 years of doing this I cannot tell you the number of times that a crash literally bricked the storage media.
Gary Little xxxxx@comcast.net
C 952-454-4629
H 952-223-1349
Tain’t what you want that makes you fat, it’s what you get.
On Jun 19, 2013, at 3:45 AM, raj_r wrote:
> @newcomer > sorry you are way off the mark local debugging is nothing but > analyzing a crash dump and event the faintest of the heart can do it > a snap shot of the state of machine is taken and windbg is led to > believe that it is looking at a crash dump is what is called local kd > (you cannot step / run / break / view registers and / or corrupt > anything except viewing some kernel mode data ) > > @pavel > > thanks > the docs still show local KD doesn’t require /debug switch > so Diane probably has to get some one clarify it i think > > https://www.google.co.in/search?q=live+local+debugging+site%3Amsdn.microsoft.com > > http://msdn.microsoft.com/en-us/library/windows/hardware/ff552017(v=vs.85).aspx > > > > On 6/19/13, xxxxx@flounder.com wrote: >> I didn’t see the original message, but debugging a driver on other than a >> “disposable” machine is extremely risky. Traditionally, this was a second >> computer, but these days the trend is to use a virtual machine. Just be >> aware that if you are debugging a driver that is running on your laptop, >> you may see it become unbootable, or bootable with serious file system >> corruption (I’ve seen both). Be prepared for the experience that after >> any run of your experimental driver, you might lose everything on that >> machine. That’s why a VM is used: you clone your target VM, and debug in >> the clone. Any damage occurs, you can trivially re-clone your VM. >> >> Then again, maybe you like juggling bowling balls while standing on thin >> ice, or juggling flaming torches while covered in flammable liquid. Local >> debugging is not for the faint of heart. >> joe >> >>> Local KD does require /debug (since Vista I believe). The system freeze >>> is >>> most likely caused by something like breakpoint in a user process which >>> gets trapped by kernel debugger. On win8 the best way to use local kd is >>> to set debugger transport to “local” (bcdedit /set dbgsettings local). >>> This will prevent the system from trying to break into debugger and >>> hanging. >>> >>> On win7 you can try disabling breaks on user mode exceptions (bcdedit >>> /set >>> noumex on). >>> >>> -----Original Message----- >>> From: xxxxx@lists.osr.com >>> [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r >>> Sent: Tuesday, June 18, 2013 3:56 AM >>> To: Kernel Debugging Interest List >>> Subject: Re: [windbg] local KD Win 7 64 bit - system freeze >>> >>> local KD aka lkd aka local kernel debugging aka live local debugging aka >>> c:> windbg -kl does not require two computers >>> >>> carlo i faintly remember going through crashes in x32 too in win7 vms and >>> reading in latest docs somewhere that lkd doesnt requre /debug switch >>> >>> try doing kd -kl or windbg -kl without /debug switch >>> >>> On 6/18/13, Danny wrote: >>>> You need 2 computers to do KD in windows: host + target. >>>> Have you read >>>> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v=vs >>>> .85).aspx >>>> ? >>>> >>>> >>>> 2013/6/18 >>>> >>>>> HI folks, >>>>> >>>>> I’ve a problem with local KD on Win 7 64 bit running on a notebook >>>>> (Sandy Bridge dual core/4GB ram) >>>>> >>>>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >>>>> I’ve activated kernel debugging using bcdedit -debug on from cmd >>>>> >>>>> Now at reboot the system freezes and there is no way to log into…to >>>>> recover just restart in safe mode deactivating debug flag… >>>>> >>>>> Help !!! >>> >>> >>> — >>> WINDBG is sponsored by OSR >>> >>> OSR is hiring!! Info at http://www.osr.com/careers >>> >>> For our schedule of WDF, WDM, debugging and other seminars visit: >>> http://www.osr.com/seminars >>> >>> To unsubscribe, visit the List Server section of OSR Online at >>> http://www.osronline.com/page.cfm?name=ListServer >>> >> >> >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Sorry I can’t find any English language website to introduce and download
the tool.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: 2013??6??18?? 18:56
To: Kernel Debugging Interest List
Subject: Re: [windbg] local KD Win 7 64 bit - system freeze
local KD aka lkd aka local kernel debugging aka live local debugging aka
c:\> windbg -kl does not require two computers
carlo i faintly remember going through crashes in x32 too in win7 vms and
reading in latest docs somewhere that lkd doesnt requre /debug switch
try doing kd -kl or windbg -kl without /debug switch
On 6/18/13, Danny wrote: > You need 2 computers to do KD in windows: host + target. > Have you read > http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v=vs > .85).aspx > ? > > > 2013/6/18 > >> HI folks, >> >> I’ve a problem with local KD on Win 7 64 bit running on a notebook >> (Sandy Bridge dual core/4GB ram) >> >> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >> I’ve activated kernel debugging using bcdedit -debug on from cmd >> >> Now at reboot the system freezes and there is no way to log into…to >> recover just restart in safe mode deactivating debug flag… >> >> Help !!! >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > > > – > Danny > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
This is incorrect. No snapshot is taken in local KD, and the debugger does not treat the session as a crash dump debugging session.
Local KD (kd -kl) does require that the system was booted with /debug on Vista or above.
S (Msft)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Wednesday, June 19, 2013 1:46 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] local KD Win 7 64 bit - system freeze
@newcomer
sorry you are way off the mark local debugging is nothing but analyzing a crash dump and event the faintest of the heart can do it a snap shot of the state of machine is taken and windbg is led to believe that it is looking at a crash dump is what is called local kd (you cannot step / run / break / view registers and / or corrupt anything except viewing some kernel mode data )
On 6/19/13, xxxxx@flounder.com wrote: > I didn’t see the original message, but debugging a driver on other > than a “disposable” machine is extremely risky. Traditionally, this > was a second computer, but these days the trend is to use a virtual > machine. Just be aware that if you are debugging a driver that is > running on your laptop, you may see it become unbootable, or bootable > with serious file system corruption (I’ve seen both). Be prepared for > the experience that after any run of your experimental driver, you > might lose everything on that machine. That’s why a VM is used: you > clone your target VM, and debug in the clone. Any damage occurs, you can trivially re-clone your VM. > > Then again, maybe you like juggling bowling balls while standing on > thin ice, or juggling flaming torches while covered in flammable > liquid. Local debugging is not for the faint of heart. > joe > >> Local KD does require /debug (since Vista I believe). The system >> freeze is most likely caused by something like breakpoint in a user >> process which gets trapped by kernel debugger. On win8 the best way >> to use local kd is to set debugger transport to “local” (bcdedit /set >> dbgsettings local). >> This will prevent the system from trying to break into debugger and >> hanging. >> >> On win7 you can try disabling breaks on user mode exceptions (bcdedit >> /set noumex on). >> >> -----Original Message----- >> From: xxxxx@lists.osr.com >> [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r >> Sent: Tuesday, June 18, 2013 3:56 AM >> To: Kernel Debugging Interest List >> Subject: Re: [windbg] local KD Win 7 64 bit - system freeze >> >> local KD aka lkd aka local kernel debugging aka live local debugging >> aka c:> windbg -kl does not require two computers >> >> carlo i faintly remember going through crashes in x32 too in win7 vms >> and reading in latest docs somewhere that lkd doesnt requre /debug >> switch >> >> try doing kd -kl or windbg -kl without /debug switch >> >> On 6/18/13, Danny wrote: >>> You need 2 computers to do KD in windows: host + target. >>> Have you read >>> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v= >>> vs >>> .85).aspx >>> ? >>> >>> >>> 2013/6/18 >>> >>>> HI folks, >>>> >>>> I’ve a problem with local KD on Win 7 64 bit running on a notebook >>>> (Sandy Bridge dual core/4GB ram) >>>> >>>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >>>> I’ve activated kernel debugging using bcdedit -debug on from cmd >>>> >>>> Now at reboot the system freezes and there is no way to log >>>> into…to recover just restart in safe mode deactivating debug flag… >>>> >>>> Help !!! >> >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
> This is incorrect. No snapshot is taken in local KD, and the debugger > does not treat the session as a crash dump debugging session. > > Local KD (kd -kl) does require that the system was booted with /debug on > Vista or above. > > - S (Msft) > > > -----Original Message----- > From: xxxxx@lists.osr.com [mailto: > xxxxx@lists.osr.com] On Behalf Of raj_r > Sent: Wednesday, June 19, 2013 1:46 AM > To: Kernel Debugging Interest List > Subject: Re: [windbg] local KD Win 7 64 bit - system freeze > > @newcomer > sorry you are way off the mark local debugging is nothing but analyzing a > crash dump and event the faintest of the heart can do it a snap shot of the > state of machine is taken and windbg is led to believe that it is looking > at a crash dump is what is called local kd (you cannot step / run / break > / view registers and / or corrupt anything except viewing some kernel mode > data ) > > @pavel > > thanks > the docs still show local KD doesn’t require /debug switch so Diane > probably has to get some one clarify it i think > > > https://www.google.co.in/search?q=live+local+debugging+site%3Amsdn.microsoft.com > > > http://msdn.microsoft.com/en-us/library/windows/hardware/ff552017(v=vs.85).aspx > > > > On 6/19/13, xxxxx@flounder.com wrote: > > I didn’t see the original message, but debugging a driver on other > > than a “disposable” machine is extremely risky. Traditionally, this > > was a second computer, but these days the trend is to use a virtual > > machine. Just be aware that if you are debugging a driver that is > > running on your laptop, you may see it become unbootable, or bootable > > with serious file system corruption (I’ve seen both). Be prepared for > > the experience that after any run of your experimental driver, you > > might lose everything on that machine. That’s why a VM is used: you > > clone your target VM, and debug in the clone. Any damage occurs, you > can trivially re-clone your VM. > > > > Then again, maybe you like juggling bowling balls while standing on > > thin ice, or juggling flaming torches while covered in flammable > > liquid. Local debugging is not for the faint of heart. > > joe > > > >> Local KD does require /debug (since Vista I believe). The system > >> freeze is most likely caused by something like breakpoint in a user > >> process which gets trapped by kernel debugger. On win8 the best way > >> to use local kd is to set debugger transport to “local” (bcdedit /set > >> dbgsettings local). > >> This will prevent the system from trying to break into debugger and > >> hanging. > >> > >> On win7 you can try disabling breaks on user mode exceptions (bcdedit > >> /set noumex on). > >> > >> -----Original Message----- > >> From: xxxxx@lists.osr.com > >> [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r > >> Sent: Tuesday, June 18, 2013 3:56 AM > >> To: Kernel Debugging Interest List > >> Subject: Re: [windbg] local KD Win 7 64 bit - system freeze > >> > >> local KD aka lkd aka local kernel debugging aka live local debugging > >> aka c:> windbg -kl does not require two computers > >> > >> carlo i faintly remember going through crashes in x32 too in win7 vms > >> and reading in latest docs somewhere that lkd doesnt requre /debug > >> switch > >> > >> try doing kd -kl or windbg -kl without /debug switch > >> > >> On 6/18/13, Danny wrote: > >>> You need 2 computers to do KD in windows: host + target. > >>> Have you read > >>> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v= > >>> vs > >>> .85).aspx > >>> ? > >>> > >>> > >>> 2013/6/18 > >>> > >>>> HI folks, > >>>> > >>>> I’ve a problem with local KD on Win 7 64 bit running on a notebook > >>>> (Sandy Bridge dual core/4GB ram) > >>>> > >>>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then > >>>> I’ve activated kernel debugging using bcdedit -debug on from cmd > >>>> > >>>> Now at reboot the system freezes and there is no way to log > >>>> into…to recover just restart in safe mode deactivating debug flag… > >>>> > >>>> Help !!! > >> > >> > >> — > >> WINDBG is sponsored by OSR > >> > >> OSR is hiring!! Info at http://www.osr.com/careers > >> > >> For our schedule of WDF, WDM, debugging and other seminars visit: > >> http://www.osr.com/seminars > >> > >> To unsubscribe, visit the List Server section of OSR Online at > >> http://www.osronline.com/page.cfm?name=ListServer > >> > > > > > > > > — > > WINDBG is sponsored by OSR > > > > OSR is hiring!! Info at http://www.osr.com/careers > > > > For our schedule of WDF, WDM, debugging and other seminars visit: > > http://www.osr.com/seminars > > > > To unsubscribe, visit the List Server section of OSR Online at > > http://www.osronline.com/page.cfm?name=ListServer > > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
The doc page is wrong for Vista and later, and has likely not been updated after XP/WS03.
S (Msft)
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rudra ???
Sent: Wednesday, June 19, 2013 8:36 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] local KD Win 7 64 bit - system freeze
Ref :
Local KD (kd -kl) does require that the system was booted with /debug on Vista or above.
On Wed, Jun 19, 2013 at 10:28 AM, Skywing > wrote: This is incorrect. No snapshot is taken in local KD, and the debugger does not treat the session as a crash dump debugging session.
Local KD (kd -kl) does require that the system was booted with /debug on Vista or above.
@newcomer sorry you are way off the mark local debugging is nothing but analyzing a crash dump and event the faintest of the heart can do it a snap shot of the state of machine is taken and windbg is led to believe that it is looking at a crash dump is what is called local kd (you cannot step / run / break / view registers and / or corrupt anything except viewing some kernel mode data )
On 6/19/13, xxxxx@flounder.commailto:xxxxx > wrote: > I didn’t see the original message, but debugging a driver on other > than a “disposable” machine is extremely risky. Traditionally, this > was a second computer, but these days the trend is to use a virtual > machine. Just be aware that if you are debugging a driver that is > running on your laptop, you may see it become unbootable, or bootable > with serious file system corruption (I’ve seen both). Be prepared for > the experience that after any run of your experimental driver, you > might lose everything on that machine. That’s why a VM is used: you > clone your target VM, and debug in the clone. Any damage occurs, you can trivially re-clone your VM. > > Then again, maybe you like juggling bowling balls while standing on > thin ice, or juggling flaming torches while covered in flammable > liquid. Local debugging is not for the faint of heart. > joe > >> Local KD does require /debug (since Vista I believe). The system >> freeze is most likely caused by something like breakpoint in a user >> process which gets trapped by kernel debugger. On win8 the best way >> to use local kd is to set debugger transport to “local” (bcdedit /set >> dbgsettings local). >> This will prevent the system from trying to break into debugger and >> hanging. >> >> On win7 you can try disabling breaks on user mode exceptions (bcdedit >> /set noumex on). >> >> -----Original Message----- >> From: xxxxx@lists.osr.commailto:xxxxx >> [mailto:xxxxx@lists.osr.commailto:xxxxx] On Behalf Of raj_r >> Sent: Tuesday, June 18, 2013 3:56 AM >> To: Kernel Debugging Interest List >> Subject: Re: [windbg] local KD Win 7 64 bit - system freeze >> >> local KD aka lkd aka local kernel debugging aka live local debugging >> aka c:> windbg -kl does not require two computers >> >> carlo i faintly remember going through crashes in x32 too in win7 vms >> and reading in latest docs somewhere that lkd doesnt requre /debug >> switch >> >> try doing kd -kl or windbg -kl without /debug switch >> >> On 6/18/13, Danny > wrote: >>> You need 2 computers to do KD in windows: host + target. >>> Have you read >>> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v= >>> vs >>> .85).aspx >>> ? >>> >>> >>> 2013/6/18 > >>> >>>> HI folks, >>>> >>>> I’ve a problem with local KD on Win 7 64 bit running on a notebook >>>> (Sandy Bridge dual core/4GB ram) >>>> >>>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >>>> I’ve activated kernel debugging using bcdedit -debug on from cmd >>>> >>>> Now at reboot the system freezes and there is no way to log >>>> into…to recover just restart in safe mode deactivating debug flag… >>>> >>>> Help !!! >> >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
> Local KD does require /debug (since Vista I believe). The system freeze is most likely caused by something like breakpoint in a user process which gets trapped by kernel debugger. On win8 the best way to use local kd is to set debugger transport to “local” (bcdedit /set dbgsettings local). This will prevent the system from trying to break into debugger and hanging.
but…I’ve set no user-mode breakpoint in any application…Why the system should itself try to break into the debugger ?
On win7 you can try disabling breaks on user mode exceptions (bcdedit /set noumex on).
yes, activating bcdedit /set noumex on and bcdedit /debug it works…
@gary
thanks
all i meant to say was local kd is not debugging at all it is merely a
facility to inspect certain kernel data structures most of them stale
by certain amount of time
for example if you successively print out TickCount in a real kernel
debugging session either between a vm and host or between two
physically connected machines the tick count of the frozen target will
not change
thanks for the correction.
i remembered reading sysinternals livekd article and assumed lkd is
similar to Sysinternals livekd
On 6/19/13, Skywing wrote: > The doc page is wrong for Vista and later, and has likely not been updated > after XP/WS03. > > - S (Msft) > > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Rudra ??? > Sent: Wednesday, June 19, 2013 8:36 AM > To: Kernel Debugging Interest List > Subject: Re: [windbg] local KD Win 7 64 bit - system freeze > > > Ref : > Local KD (kd -kl) does require that the system was booted with /debug on > Vista or above. > > But the doc at the following link > http://msdn.microsoft.com/en-us/library/windows/hardware/ff552017(v=vs.85).aspx > says > Local debugging does not require the machine to be booted with the /debug > option. > > Thanks, > --Rc > > > On Wed, Jun 19, 2013 at 10:28 AM, Skywing > > wrote: > This is incorrect. No snapshot is taken in local KD, and the debugger does > not treat the session as a crash dump debugging session. > > Local KD (kd -kl) does require that the system was booted with /debug on > Vista or above. > > - S (Msft) > > > -----Original Message----- > From: > xxxxx@lists.osr.commailto:xxxxx > [mailto:xxxxx@lists.osr.commailto:xxxxx] > On Behalf Of raj_r > Sent: Wednesday, June 19, 2013 1:46 AM > To: Kernel Debugging Interest List > Subject: Re: [windbg] local KD Win 7 64 bit - system freeze > > @newcomer > sorry you are way off the mark local debugging is nothing but analyzing a > crash dump and event the faintest of the heart can do it a snap shot of the > state of machine is taken and windbg is led to believe that it is looking at > a crash dump is what is called local kd (you cannot step / run / break / > view registers and / or corrupt anything except viewing some kernel mode > data ) > > @pavel > > thanks > the docs still show local KD doesn’t require /debug switch so Diane probably > has to get some one clarify it i think > > https://www.google.co.in/search?q=live+local+debugging+site%3Amsdn.microsoft.com > > http://msdn.microsoft.com/en-us/library/windows/hardware/ff552017(v=vs.85).aspx > > > > On 6/19/13, xxxxx@flounder.commailto:xxxxx > > wrote: >> I didn’t see the original message, but debugging a driver on other >> than a “disposable” machine is extremely risky. Traditionally, this >> was a second computer, but these days the trend is to use a virtual >> machine. Just be aware that if you are debugging a driver that is >> running on your laptop, you may see it become unbootable, or bootable >> with serious file system corruption (I’ve seen both). Be prepared for >> the experience that after any run of your experimental driver, you >> might lose everything on that machine. That’s why a VM is used: you >> clone your target VM, and debug in the clone. Any damage occurs, you can >> trivially re-clone your VM. >> >> Then again, maybe you like juggling bowling balls while standing on >> thin ice, or juggling flaming torches while covered in flammable >> liquid. Local debugging is not for the faint of heart. >> joe >> >>> Local KD does require /debug (since Vista I believe). The system >>> freeze is most likely caused by something like breakpoint in a user >>> process which gets trapped by kernel debugger. On win8 the best way >>> to use local kd is to set debugger transport to “local” (bcdedit /set >>> dbgsettings local). >>> This will prevent the system from trying to break into debugger and >>> hanging. >>> >>> On win7 you can try disabling breaks on user mode exceptions (bcdedit >>> /set noumex on). >>> >>> -----Original Message----- >>> From: >>> xxxxx@lists.osr.commailto:xxxxx >>> [mailto:xxxxx@lists.osr.commailto:xxxxx] >>> On Behalf Of raj_r >>> Sent: Tuesday, June 18, 2013 3:56 AM >>> To: Kernel Debugging Interest List >>> Subject: Re: [windbg] local KD Win 7 64 bit - system freeze >>> >>> local KD aka lkd aka local kernel debugging aka live local debugging >>> aka c:> windbg -kl does not require two computers >>> >>> carlo i faintly remember going through crashes in x32 too in win7 vms >>> and reading in latest docs somewhere that lkd doesnt requre /debug >>> switch >>> >>> try doing kd -kl or windbg -kl without /debug switch >>> >>> On 6/18/13, Danny >>> > wrote: >>>> You need 2 computers to do KD in windows: host + target. >>>> Have you read >>>> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v= >>>> vs >>>> .85).aspx >>>> ? >>>> >>>> >>>> 2013/6/18 > >>>> >>>>> HI folks, >>>>> >>>>> I’ve a problem with local KD on Win 7 64 bit running on a notebook >>>>> (Sandy Bridge dual core/4GB ram) >>>>> >>>>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >>>>> I’ve activated kernel debugging using bcdedit -debug on from cmd >>>>> >>>>> Now at reboot the system freezes and there is no way to log >>>>> into…to recover just restart in safe mode deactivating debug flag… >>>>> >>>>> Help !!! >>> >>> >>> — >>> WINDBG is sponsored by OSR >>> >>> OSR is hiring!! Info at http://www.osr.com/careers >>> >>> For our schedule of WDF, WDM, debugging and other seminars visit: >>> http://www.osr.com/seminars >>> >>> To unsubscribe, visit the List Server section of OSR Online at >>> http://www.osronline.com/page.cfm?name=ListServer >>> >> >> >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — WINDBG is sponsored by OSR OSR is hiring!! Info at > http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other > seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List > Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
> Local KD does require /debug (since Vista I believe). The system freeze is most likely caused by something like breakpoint in a user process which gets trapped by kernel debugger. On win8 the best way to use local kd is to set debugger transport to “local” (bcdedit /set dbgsettings local). This will prevent the system from trying to break into debugger and hanging.
but…I’ve set no user-mode breakpoint in any application…Why the system should itself try to break into the debugger ?
There are many thousands of applications on your Windows system that you
didn’t write, including a large number that Microsoft didn’t write,
either. Some of them are not good neighbors and fire assertions
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Or your very own driver has corrupted memory and the IP suddenly found itself executing random instructions. Hopefully one of them was a breakpoint before things went totally kaboom.
Gary Little xxxxx@comcast.net
C 952-454-4629
H 952-223-1349
Tain’t what you want that makes you fat, it’s what you get.
On Jun 19, 2013, at 12:51 PM, Tim Roberts wrote:
> xxxxx@alice.it wrote: >>> Local KD does require /debug (since Vista I believe). The system freeze is most likely caused by something like breakpoint in a user process which gets trapped by kernel debugger. On win8 the best way to use local kd is to set debugger transport to “local” (bcdedit /set dbgsettings local). This will prevent the system from trying to break into debugger and hanging. >> but…I’ve set no user-mode breakpoint in any application…Why the system should itself try to break into the debugger ? > > There are many thousands of applications on your Windows system that you > didn’t write, including a large number that Microsoft didn’t write, > either. Some of them are not good neighbors and fire assertions > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
sorry you are way off the mark local debugging is nothing but
analyzing a crash dump and event the faintest of the heart can do it
a snap shot of the state of machine is taken and windbg is led to
believe that it is looking at a crash dump is what is called local kd
(you cannot step / run / break / view registers and / or corrupt
anything except viewing some kernel mode data )
But if all you are doing is reading crash dumps from some other sysyem,
that is not “local debugging” and the state of /debug is irrelevant.
Local debugging means you are running the debugger on the same machine as
your driver. Running a debugger suggests that the driver is not working
correctly, or you wouldn’t need to debug it. The driver not working
correctly means the behavior of the driver is undefined. Undefined driver
behavior has an extremely high probability of hosing your disk and making
everything on it inaccesible. On good days, the damage is lifhter and you
might only lose a few hundred files or directories.
I stand by my observation: local debugging is not fot the faint of heart.
It most emphatically is NOT “nothing but a crash dump”.
You don’t have to agree with me, or even believe me, but when a bad driver
turns your laptop into a content-free paperweight, I will feel free to say
“I told you so”.
Perhaps you are living in a fantasy world in which you have not yet seen
this phenomenon. Those of us living in the real world of driver
development know this happens, and fairly often. If this is your only
computer, you will pay a high price the first tine this happens and you
lose eerything on your disk, including the source to your “almost working”
driver. If, on the other hand, you are keeping everything on another
machine, downloading it to your laptop, and using local debugging because
you can’t get a reliable serial/USB/1394/network conection to do
host/target debugging, fine, your laptop is entirely sacrificial, and you
will be prepared to install Windows again potentially after EVERY BSOD.
If you don’t have to reinstall Windows after a test, think of it as
dodging a bullet. You can’t get away with this forever.
But you did not explain that your laptop is 100% sacrificial, and I
reacted as most developers do when someone has to ask about local
debugging: that they are debugging on their development machine. There is
no way to overstate the case that this is A Really Bad Idea, Quite
Possibly The Worst Idea, Ever.
The issue is not with your ability to corrupt kernel data from the
debugger. The issue is with the fact that an erroneous driver is more than
capable of doing this without any help.
joe
On 6/19/13, xxxxx@flounder.com wrote: >> I didn’t see the original message, but debugging a driver on other than >> a >> “disposable” machine is extremely risky. Traditionally, this was a >> second >> computer, but these days the trend is to use a virtual machine. Just >> be >> aware that if you are debugging a driver that is running on your laptop, >> you may see it become unbootable, or bootable with serious file system >> corruption (I’ve seen both). Be prepared for the experience that after >> any run of your experimental driver, you might lose everything on that >> machine. That’s why a VM is used: you clone your target VM, and debug >> in >> the clone. Any damage occurs, you can trivially re-clone your VM. >> >> Then again, maybe you like juggling bowling balls while standing on thin >> ice, or juggling flaming torches while covered in flammable liquid. >> Local >> debugging is not for the faint of heart. >> joe >> >>> Local KD does require /debug (since Vista I believe). The system freeze >>> is >>> most likely caused by something like breakpoint in a user process which >>> gets trapped by kernel debugger. On win8 the best way to use local kd >>> is >>> to set debugger transport to “local” (bcdedit /set dbgsettings local). >>> This will prevent the system from trying to break into debugger and >>> hanging. >>> >>> On win7 you can try disabling breaks on user mode exceptions (bcdedit >>> /set >>> noumex on). >>> >>> -----Original Message----- >>> From: xxxxx@lists.osr.com >>> [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r >>> Sent: Tuesday, June 18, 2013 3:56 AM >>> To: Kernel Debugging Interest List >>> Subject: Re: [windbg] local KD Win 7 64 bit - system freeze >>> >>> local KD aka lkd aka local kernel debugging aka live local debugging >>> aka >>> c:> windbg -kl does not require two computers >>> >>> carlo i faintly remember going through crashes in x32 too in win7 vms >>> and >>> reading in latest docs somewhere that lkd doesnt requre /debug switch >>> >>> try doing kd -kl or windbg -kl without /debug switch >>> >>> On 6/18/13, Danny wrote: >>>> You need 2 computers to do KD in windows: host + target. >>>> Have you read >>>> http://msdn.microsoft.com/zh-CN/library/windows/hardware/hh439378(v=vs >>>> .85).aspx >>>> ? >>>> >>>> >>>> 2013/6/18 >>>> >>>>> HI folks, >>>>> >>>>> I’ve a problem with local KD on Win 7 64 bit running on a notebook >>>>> (Sandy Bridge dual core/4GB ram) >>>>> >>>>> Installation of Debugging Tools x64 from SDK 7.1 goes fine and then >>>>> I’ve activated kernel debugging using bcdedit -debug on from cmd >>>>> >>>>> Now at reboot the system freezes and there is no way to log into…to >>>>> recover just restart in safe mode deactivating debug flag… >>>>> >>>>> Help !!! >>> >>> >>> — >>> WINDBG is sponsored by OSR >>> >>> OSR is hiring!! Info at http://www.osr.com/careers >>> >>> For our schedule of WDF, WDM, debugging and other seminars visit: >>> http://www.osr.com/seminars >>> >>> To unsubscribe, visit the List Server section of OSR Online at >>> http://www.osronline.com/page.cfm?name=ListServer >>> >> >> >> >> — >> WINDBG is sponsored by OSR >> >> OSR is hiring!! Info at http://www.osr.com/careers >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at >> http://www.osronline.com/page.cfm?name=ListServer >> > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
What does this observation have to do with anything? I don’t even know te
difference between “truly debug” and whatever LiveKd does, and it foesn’t
matter. An erroneous driver can corrupt the entire hard drive. I’ve seen
it happen. So have most (or perhaps all) of the experienced developers on
this list.
joe