Application Trace Profiler

[Guest]

Does anyone have an example of an application that can connect to a running
process and capture Trace.WriteLine calls like in SQL Server Profiler? I
know that we can inherit from a TraceListener class to write to files,
databases, etc..., but I would really like to attach to running .NET
processes and get the results without any logging and instead capture the
real-time results when troubleshooting.

 

[W.G. Ryan - MVP]

Bryan:

I'm not sure I follow you. Let's say you have some App called SomeApp. Are
you wanting to just attach to it and find out what's going on with it? It's
going to need to have output of some sort to do this other than your basic
Perfmon stuff (which is quite powerful). can you tell me a little more
about what exactly you need to do? I'll do what I can from there.

Cheers,

Bill

 

[Guest]

Basically yes, I just want to monitor what is happening with the application
with the Trace statements in the code. I'm not really looking for statistics
with Perfmon, but rather key statements or checkpoints of the executing code,
parameters, etc.. Take SQL Server Profiler as an example. You're able to
see realtime executing SQL statements when running the profiler. I would
like to replicate something similar to attach to "SomeApp" when it's running
and view it's progress, especially for troubleshooting purposes. Another
example, is Visual Studio's output window that captures Debug.Write() and
Trace.Write() statements and displays the output to the window. Of course,
I'm trying to do all this by taking advantage of the .NET framework (which I
can create my own TraceListener), but I would really prefer to capture the
Trace statements without logging to a file or database; only capturing the
output when the custom profiler is profiling the .NET application, "SomeApp."

 

[W.G. Ryan - MVP]

Bryan:

I think I can help you out on this, but where would you want to review the
information that you get back? Are you thinking of something like building
your own "profiler' for your application, having something like the
console/output windows or something of that sort?

 

[Guest]

Exactly, I'm thinking of a very simple profiler application that will
intercept the Trace statements of another running .NET application.

From what I've been reading so far, if there are no trace listeners attached
to a running process the Trace messages are outputted using the
OutputDebugString API. I'm wondering if there is a way that I can find an
API call that will safely listen for the OutputDebugString call and display
the message to the profiler's screen.

 

[Charles Law]

Hi Bryan

I'm wondering if there is a way that I can find an
API call that will safely listen for the OutputDebugString call and
display
the message to the profiler's screen.

There is, and you can.

You call DebugActiveProcess() to hook into the target process, and then go
into a loop calling WaitForDebugEvent(). If WaitForDebugEvent() returns True
then you have a debug event, and you can look for OUTPUT_DEBUG_STRING_EVENT.

In order to read the string output you will have to read the memory in the
target process and marshal it back to your trace process.

Have a look here:

http://www.codeproject.com/useritems/VB_Debugger2.asp

HTH

Charles

 

[Guest]

Hi Charles,

I tried this article and I was able to profile the Trace messages from my
application exactly the way I wanted, but I did notice that when the
"profiling" application exits it kills the application being traced. Is
there any way to detach from the application so that the profiler can exit
without killing the application being profiled?

Thanks!
Bryan

 

[Charles Law]

Hi Bryan

I have my debug event handling loop in a background thread, and before
entering the loop I call DebugSetProcessKillOnExit(False). When I want to
stop debugging I exit the loop, call DebugActiveProcessStop, and allow the
thread to terminate. The process that I am debugging then continues to run.

Are you connecting to an already running process, or do you start the
process in your debugger? Either way, the above should work.

HTH

Charles

 

[Guest]

This worked like a charm! Thanks so much Charles!