Re: Getting proper Stack information from memory dump

From: Rishan (anon_at_anon.com)
Date: 11/11/04 

Date: Thu, 11 Nov 2004 09:56:06 -0500

Hi,

I just would like to confirm that in order to see detailed stack
information, the original ASP.net app that I'm trying to debug must have
been built in "Debug" mode. The dump I currently have is about a week old,
when the app in production was built in "Release" mode. When I try to view
stack information, it says the thread is not a managed thread. If it had
been built in Debug mode, it would have recognized the thread as managed
correct?

Thanks,

Rishan

"Jim Cheshire [MSFT]" <jamesche@online.microsoft.com> wrote in message
news:eyMNNFqxEHA.2916@cpmsftngxa10.phx.gbl...
> Hi Rishan,
>
> As Bruce said, you want to use the SOS extension for debugging managed
> code. You can get it from the v1.1.4322 folder. Open your dump in Windbg
> and then enter the following command to load it:
>
> load c:\\windows\\microsoft.net\\framework\\v1.1.4322\\sos
>
> After it's loaded, you can use several methods to view the stack:
>
> !clrstack
>
> That will show you managed code in the stack. You can get more detail by
> running:
>
> !clrstack -a
>
> If you've already got Perfmon data that shows which threads are the issue,
> that should be all you need. If you'd like even more information on those
> threads, try this:
>
> !dumpstack
>
> That will give you a lot more information.
>
> Let me know if that helps you.
>
> Jim Cheshire [MSFT]
> MCP+I, MCSE, MCSD, MCDBA
> ASP.NET Developer Support
> jamesche@online.microsoft.com
>
> This post is provided "AS-IS" with no warranties and confers no rights.
>
>
> --------------------
> | From: "Microsoft News Server" <anon@anon.com>
> | Subject: Getting proper Stack information from memory dump
> | Date: Tue, 9 Nov 2004 14:45:35 -0500
> | Lines: 26
> | X-Priority: 3
> | X-MSMail-Priority: Normal
> | X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
> | X-RFC2646: Format=Flowed; Original
> | Message-ID: <Op4DvSpxEHA.2996@TK2MSFTNGP10.phx.gbl>
> | Newsgroups: microsoft.public.dotnet.framework.aspnet
> | NNTP-Posting-Host: 206.47.190.38
> | Path:
> cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10
> phx.gbl
> | Xref: cpmsftngxa10.phx.gbl
> microsoft.public.dotnet.framework.aspnet:274812
> | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
> |
> | Hi,
> |
> | I am currently having a problem with random, intermittent lock ups in my
> | ASP.net application on our production server (99% CPU usage by 3
> threads,
> | indefinately). I currently use IIS Debug Tools to do a memory dump of
> the
> | app when the lock up occurs, however the stack information is not very
> | useful.
> |
> | I have just put a new build of our system onto production, and this
> build
> is
> | a "Debug" build as opposed to a "Release" build. I am hoping to get more
> | information from the dump, like which lines of code are being executed
> in
> | the web app.
> |
> | Is there anything else I need to setup in order to get this level of
> detail
> | out of the dump. Right now, I am just getting Kernel calls, and the
> three
> | threads always lock up with the last call being:
> |
> | KERNEL32!lstrcmpiw+0xbz
> |
> | I am using Windbg to load and view the memory dump files.
> |
> | Thanks,
> |
> | Rishan
> |
> |
> |
>

Relevant Pages

  • Re: stack becomes empty when debugging with a breakpoint?
    ... > app. ... However when I try to debug it the ... > stack becomes empty any time it is accessed after a breakpoint is hit. ...
    (microsoft.public.dotnet.framework)
  • Re: Need Help Debugging
    ... you should use straight and plain ADPlus.VBS from the debugger package. ... debug info loaded, etc... ... does that avoid using the stack ?!? ... which is our custom CRITICAL_SECTION class. ...
    (microsoft.public.win32.programmer.kernel)
  • [PATCH] i386: get rid of the use of KPROBE_ENTRY / KPROBE_END
    ... * Debug traps and NMI can happen at the one SYSENTER instruction ... * that sets up the real kernel stack. ... * a debug fault, and the debug fault hasn't yet been able to ...
    (Linux-Kernel)
  • Re: Ecos, LwIP, PPP and GPRS
    ... the modem has an IP stack built in. ... FTP is the most important right now. ... >>while printing the messages over another serial port. ... >Can you modify the debug output to go to a memory buffer instead of the ...
    (comp.arch.embedded)
  • Re: Problem only in release version!
    ... Debug version may still have the problem, but the stack space is better ... memory or a buffer on the stack is not always caught. ... > Just to affirm Jochen's point, the Debug version initializes most ...
    (microsoft.public.dotnet.languages.vc)
Quantcast