Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Go Back   OSR Online Lists > windbg
Welcome, Guest
You must login to post to this list
  Message 1 of 7  
11 Sep 17 05:24
cm it
xxxxxx@gmail.com
Join Date: 11 Sep 2017
Posts To This List: 3
BugCheck 51

HI, I'm new here. i'm a sys admin for a living. My main focus is SCCM, AD, Powershell, WPA. I have used WinDB in the past to solve a USB issue. I had a look into some basic commands and with a lot of patience i was able to solve the issue. Windb kept my interest. The only downside for me is the lack of a good introduction into it. Anyway, i have a computer that has the following bugcode: BugCheck 51 It appear to be caused by the registry. I found this article online: https://vallejo.cc/2015/03/23/debugging-bsod-trying-to-delete-malformed-registry- key-on-windows-8-1/ i tried to follow it but his stack is pretty different from mine. Add to that the fact that my knowledge of commands is low, its pretty hard to follow. how do i start debugging this? is there any documentation that explain this mans reasoning and maybe the basic idea behind it? I get that he unravels the code from memory but i don't understand the "parameter and pointers" part nor how they are linked. So i guess i'm asking for a place with more guides/tutorials/documentation that walks you trough a bit more. I could upload my BSOD if someone would like to make some sort of "walkthrough". cheers
  Message 2 of 7  
11 Sep 17 12:17
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 487
BugCheck 51

xxxxx@gmail.com wrote: > I'm new here. i'm a sys admin for a living. My main focus is SCCM, AD, Powershell, WPA. I have used WinDB in the past to solve a USB issue. I had a look into some basic commands and with a lot of patience i was able to solve the issue. Windb kept my interest. The only downside for me is the lack of a good introduction into it. > > Anyway, i have a computer that has the following bugcode: BugCheck 51 > It appear to be caused by the registry. > ... > i tried to follow it but his stack is pretty different from mine. Add to that the fact that my knowledge of commands is low, its pretty hard to follow. > > how do i start debugging this? Well, I don't mean to be a Negative Nellie, but I think the practical answer is "you don't".  Either there is bad information written to the registry, or something nefarious is mangling the data on the way in.  If there is bad information written to the registry, then the solution is to reload the registry from a backup, or reinstall Windows. If something is mangling the data, then you have a memory error or a virus.  You can test for memory problems, but a virus will require a reinstall. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 3 of 7  
12 Sep 17 03:41
cm it
xxxxxx@gmail.com
Join Date: 11 Sep 2017
Posts To This List: 3
BugCheck 51

It's not a virus, i'm sure of that. Having said that, i wanted to use this particular case as a learning-moment. We have spare computers enough so it's already replaced, i have no time pressure solving this. I just wanted to try and come up with a WinDB analysis like the one i referred to. And on the other hand i was hoping on some resources that can help me to learn some new stuff. The resource i'm looking for kinda explains the general idea behind de debugger. Like i know how to list the modules, ask for computer specs, see the stack, find the last frame. But i can't "interact" with the stack, i don't really know what i'm looking at and for (a part from what i believe are memory addresses). But i haven't found documentation that explains really. Thanks for your reply btw
  Message 4 of 7  
12 Sep 17 11:04
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 546
List Moderator
BugCheck 51

I teach lots of people how to debug Windows crash dumps. It's not easy as there's TONS of information you need in order to really get proficient at it. Assuming that we're talking about general purpose kernel debugging, I've found that it requires a mix of the following: 1. Understanding of the C programming language 2. Understanding of assembly 3. Understanding of the Windows operating system (overall architecture, core concepts) 4. Understanding of computer architecture 5. Patience and perseverance...Crash dumps analysis is hard and it takes a certain kind of to person get up and put their pants on day after day knowing that they're going to stare at the same problem again. I try to jump start everyone with this stuff during our 5 day debug lab (except #5, you need that already :)). I don't know of anywhere you can go to read an A-Z "this is how you get into kernel debugging." That being said, if you put the dump someplace I can try to walk through it if you don't mind me sharing the result. -scott OSR @OSRDrivers wrote in message news:66657@windbg... It's not a virus, i'm sure of that. Having said that, i wanted to use this particular case as a learning-moment. We have spare computers enough so it's already replaced, i have no time pressure solving this. I just wanted to try and come up with a WinDB analysis like the one i referred to. And on the other hand i was hoping on some resources that can help me to learn some new stuff. The resource i'm looking for kinda explains the general idea behind de debugger. Like i know how to list the modules, ask for computer specs, see the stack, find the last frame. But i can't "interact" with the stack, i don't really know what i'm looking at and for (a part from what i believe are memory addresses). But i haven't found documentation that explains really. Thanks for your reply btw
  Message 5 of 7  
12 Sep 17 13:49
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 487
BugCheck 51

xxxxx@gmail.com windbg"@lists.osr.com wrote: > Having said that, i wanted to use this particular case as a learning-moment. > We have spare computers enough so it's already replaced, i have no time pressure solving this. > > I just wanted to try and come up with a WinDB analysis like the one i referred to. And on the other hand i was hoping on some resources that can help me to learn some new stuff. In this particular case, windbg may not be the right tool.  If you are really interested in a project, you can try reverse engineering the format of the registry files, to see if you can find where the flaw exists.  There are documents on the web that would help with that.  I still doubt you can fix it; you may find that a whole sector was written as 0s, for example, and that's not really recoverable. > The resource i'm looking for kinda explains the general idea behind de debugger. Like i know how to list the modules, ask for computer specs, see the stack, find the last frame. But i can't "interact" with the stack, i don't really know what i'm looking at and for (a part from what i believe are memory addresses). Well, you can't really "interact" with the stack.  You can disassemble code, you can change registers, and you can tweak memory values, but once you have a bugcheck, the system is hosed.  You can't "resume" execution in any meaningful way. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 6 of 7  
18 Sep 17 03:57
cm it
xxxxxx@gmail.com
Join Date: 11 Sep 2017
Posts To This List: 3
BugCheck 51

>1. Understanding of the C programming language I don't know C. >2. Understanding of assembly RIP >3. Understanding of the Windows operating system (overall architecture, core >concepts) I've read quite a few chapters of Windows Internals books, so i have a frame of reference. >4. Understanding of computer architecture Again, some frame of reference. >5. Patience and perseverance...Crash dumps analysis is hard and it takes a >certain kind of to person get up and put their pants on day after day >knowing that they're going to stare at the same problem again. Thats no issue, i've done this in the past. For instance, on my small (very personal) blog: https://cookiecrumbles.github.io/BSOD-all-over-the-place/ I've done that analysis based on whatever i could find on the net, took me a lot of time tho. >I try to jump start everyone with this stuff during our 5 day debug lab >(except #5, you need that already :)). I don't know of anywhere you can go >to read an A-Z "this is how you get into kernel debugging." Well i'm not gonna get money from my bosses for a 5-day training for something i'm not gonna use that often (at least at this job). And i'm concluding that i'm not gonna find more info on the net than i already did? >That being said, if you put the dump someplace I can try to walk through it >if you don't mind me sharing the result. I don't have a case atm. But maybe you have some cases (in the forum) that can learn me a few things ? Thanks for the reply and info. Sorry for the late response but it's pretty busy atm.
  Message 7 of 7  
19 Sep 17 09:14
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 546
List Moderator
BugCheck 51

Your blog post shows you're on the right path, lots of picking through structures and jumping to some logical conclusions. From an IT perspective you're mostly trying to come up with reasonable things to try to help resolve the problem (e.g. "this is a crash in the file system, so let me check the timestamp on the AV drivers and see if there's an update"). I try to write about debugging related things when I can (debugging it somewhat of a hobby of mine...): https://www.osr.com/blog/category/debug/ The ntdebugging blog always did a nice job on their crash walkthroughs, though they haven't updated in a while: https://blogs.msdn.microsoft.com/ntdebugging/ Maybe others have more. -scott OSR @OSRDrivers wrote in message news:66662@windbg... >1. Understanding of the C programming language I don't know C. >2. Understanding of assembly RIP >3. Understanding of the Windows operating system (overall architecture, >core >concepts) I've read quite a few chapters of Windows Internals books, so i have a frame of reference. >4. Understanding of computer architecture Again, some frame of reference. >5. Patience and perseverance...Crash dumps analysis is hard and it takes a >certain kind of to person get up and put their pants on day after day >knowing that they're going to stare at the same problem again. Thats no issue, i've done this in the past. For instance, on my small (very personal) blog: https://cookiecrumbles.github.io/BSOD-all-over-the-place/ I've done that analysis based on whatever i could find on the net, took me a lot of time tho. >I try to jump start everyone with this stuff during our 5 day debug lab >(except #5, you need that already :)). I don't know of anywhere you can go >to read an A-Z "this is how you get into kernel debugging." Well i'm not gonna get money from my bosses for a 5-day training for something i'm not gonna use that often (at least at this job). And i'm concluding that i'm not gonna find more info on the net than i already did? >That being said, if you put the dump someplace I can try to walk through it >if you don't mind me sharing the result. I don't have a case atm. But maybe you have some cases (in the forum) that can learn me a few things ? Thanks for the reply and info. Sorry for the late response but it's pretty busy atm.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the windbg list to be able to post.

All times are GMT -5. The time now is 13:40.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license