Debugging BSOD(转)

  
新闻群组    
 高级群组搜寻      
  
  
Groups search result 6 for  

 
寄件者：Doug Kehn (dougkehn@csi.com)
主旨：Re: Debugging BSOD
新闻群组：comp.os.ms-windows.programmer.nt.kernel-mode
View: Complete Thread (6 articles) | Original Format
日期：1999/12/17
 

I\'ve been toying with a method to debug BSOD that maybe someone can confirm
(or at least tell me I\'m wrong).  I\'ve been using this method and it SEEMS
to work but maybe I\'ve been getting lucky.  I needed something to track down
a
bugcheck that only occurred on free builds with no debugger running.  I also
had
the misfortune that no MEMORY.DMP file was generated when the bugcheck
happened.

You need to generate a MAP (preferably with line information) file for your
driver.
Then use the first two lines of the BSOD.

Looking at the first two lines of the BSOD, if the second line denotes your
driver then take the two addresses (from the second line) and subtract them
and then add 10000h. The value 10000h is obtained from the \'Preferred load
address is\' line of the MAP file.  Using the map file for your driver find
the first
\'Rva+base\' value that is not over the computed value.  This will give you
the function
where the bugcheck occurred.  Subtract the \'Rva+base\' value from the
computed value
and add the result to the \'Address\' column value.  This result will give you
line
number where the bugcheck happened.  Go to the line number information for
the OBJ file where the bugcheck happened and find the first value that is
not over the computed line number value.  This should be the line number
within the file (and within the function) where the bugcheck happened.

For example (the data is fictional):

*** STOP 0x0000000A (0x00000000, 0x00000002, 0x00000000, 0xFE302649)
IRQL_NOT_LESS_OR_EQUAL*** Address FE302649 has base at FE300000 - MyDrv.sys

*********************************************************

  Address               Publics by Value        Rva+Base     Lib:Object

 0004:00000194       _MyFunction1@4    00012574 f   main.obj
 0005:00000062       _DriverEntry@8       000126e2 f   main.obj

        :
        :

Line numbers for obj\\i386\\main.obj(D:\\MyDrv\\main.c) segment .text

   261 0001:000018f0   263 0001:000018f6   264 0001:000018fd   265
0001:00001904
   266 0001:0000190c   268 0001:00001914   270 0001:0000191c   271
0001:00001922
   273 0001:0000192d   274 0001:00001933   277 0001:00001935   278
0001:0000193b
   279 0001:00001943   281 0001:00001945   282 0001:00001948

The calculation is:

 FE302649
-FE300000
+      10000    Taken from \'Preferred load address is\' in MAP file
----------------
         12649
-        12574   Taken from \'Rva+base\' column in MAP file
----------------
               D5
+           194   Taken from \'Address\' column in MAP file
-----------------
             269

The bugcheck occured on line 268 of MAIN.C in function MyFunction1.


<matthewstewart@my-deja.com> wrote in message
news:83b4dr$4vs$1@nnrp1.deja.com...
> In article <TR9ZOOdi0au5D4MUMeAsta0+mxC4@4ax.com>,
>   Mark Roddy <markr@wattanuck.mv.com> wrote:
> > On Thu, 16 Dec 1999 09:57:41 GMT, matthewstewart@my-deja.com wrote:
> >
> > >
> > >
> > >> > Is there any good way to trace the cause of BSOD ?
> > >> > I have softice. Can it help me ?
> > >>
> > >> Soft-Ice will popup when KeBugCheckEx is entered. You can often do a
> > >> STACK command at that point and trace back to a point in your own code
> > >> where you\'re doing something wrong.
> > >
> > >
> > >Can WinDbg be used to debug a crashdump?  I have tried and got nowhere.
> > >
> >
> > Yes of course it can, for some value of windbag. The W2K RC2 version
> > of windbag was unable to debug anything reliably, including crash
> > dumps, but that \"release\" of windbag was a bit of an abberation.
> > Hopefully the RC3 and RC4(aka SP0) \"releases\" of windbag will be a
> > little better on the quality side.
> >
> > Windbag ought to have a startup option, let\'s see... currently it\'s
> > under the File\\Open Crash Dump... menu, that will let you browse for a
> > crash dump file and then analyze it as if you were plugged into a live
> > system.
> >
> > The tricky part, as always,  is getting windbag pointed at the right
> > set of symbols. If it is your test system that crashed this is
> > generally easy to do. If on the other hand you are doing customer
> > support, you may be iterating for a while trying to find the correct
> > os version, service pack, misc. cruft that represents the customer
> > system.
> >
> > Once you get symbols resolved, the kernel debugger extensions (regular
> > and the oemtools extensions) are really quite good at helping you
> > analyze what went wrong.
> >
> > You can also try dumpanal and dumpchk, the latter is generally pretty
> > good at testing if the dump is even worth looking at to begin with,
> > the former doesn\'t appear on the RC3 ddk so its status is a bit
> > nebulous.
> >
> > Mark Roddy
> > Independent WindowsNT Consultant
> > markr@wattanuck.mv.com
>
>
> No wonder I couldn\'t get any where!
>
> The CD with WinDbg on is from \'96, so I guess its pretty old!
>
> Since the company I work for wont even subscribe to the MSDN, the
> chance of getting SoftIce or any other tool is pretty slim.
>
> I shall have to struggle on!
>
> Thanks any way.
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


--------------------------------------------------------------------------------
  

?2002 Google