[PowerShell Script] Saving a Module from a .NET Method Call

re: [PowerShell Script] Saving a Module from a .NET method call

nativecpp — Mon, 10 Sep 2007 19:15:26 GMT

Hi Roberto,

I have a general question on .Net and I thought you may have some ideas on how to solve this:

Let say I have an app that I use try/catch to catch some system.exception such as division by zero. After catching this error, I could get the current stack frame from my app. Is there a way to dump the contents of all local vars (w/o var names) and params w/o using windbg (and SOS) and symbols.

I tried to use reflection but seems there is not much I could do in reflection.

If you could give me some ideas or link to some documents, I would appreciate that.

Thanks

re: [PowerShell Script] Saving a Module from a .NET method call

Roberto Farah — Mon, 10 Sep 2007 20:19:21 GMT

Hi nativecpp,

Without using Windbg and symbols I'd think about logging trace information.

Within the catch block you could log the stack trace and frames using System.Diagnostics:

http://msdn2.microsoft.com/en-us/library/system.diagnostics.stackframe.aspx

http://msdn2.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx

Besides your methods could save the content from the local variables or the most important local variables.

Then when you check the log file or Event log you will have the stack trace and the most important local variables.

It is a proactive approach using trace information: the application itself logs the stack from the exception and, as part of the execution flow, the important variables are always logged at different points of the same method call. When you analyze the log you will have the stack trace and the local variables from all stack frames in previous log entries.

Thanks

re: [PowerShell Script] Saving a Module from a .NET method call

Roberto Farah — Tue, 11 Sep 2007 03:00:58 GMT

Attention! I just fixed two minor bugs:

- The MetaData start address was not being displayed.

- The !dumpmodule was replaced by !DumpModule because I had some problems with our internal SOS version.

Please, make sure to use this updated version.

re: [PowerShell Script] Saving a Module from a .NET method call

nativecpp — Tue, 11 Sep 2007 18:24:25 GMT

Hi Roberto,

Thanks for the suggestopns. I did use stackframe to log as much info as possible, I think. But I would like to automatically dump at least params and some local vars (may be 1st nth ones)w/o having the catcher to do that.

I am just wondering if there is a way to do dumping if I have a stack frame and whether I can do follow those SOS commands ??

Thanks

re: [PowerShell Script] Saving a Module from a .NET method call

Roberto Farah — Tue, 11 Sep 2007 19:35:02 GMT

Hi nativecpp,

The local variables and parameters should be logged outside the catch block. Doing so you will end up having information from the local var and parameters aside of having an exception, like I mentioned before.

Another approach: your application could create a dump when handling a specific exception. To do that it should use MiniDumpWriteDump API function from DBGHELP.DLL.

http://msdn2.microsoft.com/en-us/library/ms680360.aspx

http://msdn2.microsoft.com/en-us/library/bb204861.aspx

The SOSEX extension helps to get the local variables: http://www.stevestechspot.com/SOSEXANewDebuggingExtensionForManagedCode.aspx

Another approach: Within the catch handler you can use Trace.WriteLine("WINDBGCMD: <execute commands here>"). To do that you need to use .ocommand WINDBGCMD from the debugger window. Using this approach you can attach the debugger to the application and when the exception happens the debugger recognizes the command string prefix WINDBGCMD and execute the commands you want. Doing that you would be able to see the local variables.

Thanks

re: [PowerShell Script] Saving a Module from a .NET Method Call

Joe — Fri, 12 Oct 2007 00:10:07 GMT

You scripts are amazing! I´m waiting for the next PowerDbg script.

Keep doing this great work!

Joe

[PowerShell Script] Isolating the Threads Consuming High CPU

Debugging Toolbox — Tue, 25 Dec 2007 03:51:09 GMT

When helping my customers with scenarios in which the symptom is high CPU, I very often end up with only

[PowerShell Script] PowerDbg v5.0—Using PowerShell to Control WinDbg

Debugging Toolbox — Wed, 04 Feb 2009 08:05:58 GMT

I’m very excited to present the new PowerDbg v5.0! There’s just one change, but it’s a HUGE change that

[PowerShell Script] PowerDbg v5.1—Using PowerShell to Control WinDbg

Debugging Toolbox — Fri, 20 Mar 2009 03:40:47 GMT

So, here we go again. This is a minor version with a few new cmdlets. These new cmdlets are those that

[PowerShell Script] PowerDbg v5.2—Using PowerShell to Control WinDbg

Debugging Toolbox — Wed, 29 Apr 2009 19:15:36 GMT

This version has two improvements and some scripts were changed to be compatible with this new version: