I wonder if, since DbgView is a freeware tool, the author of that
program would be willing to share the technique(s) he uses in that
program to capture those outputs? Can't imagine it would hurt to email
him and ask.
[quoted text, click to view] "jdmcfadden" <jimUNDERSCOREmcfaddenATcomcastDOTnet> wrote in message news:<EA112709-D41F-4AF3-A10E-411D33B5485B@microsoft.com>...
> No, that won't work. The point is to have a real-time display of the
OutputDebugString data, such as debuggers like DbgView provide. It's
essentially a tool for the operations people to use to be able to just
start, point to a given service, eyeball the output and say, "Yup,
everything's fine". The designers do not consider logfiles realtime
enough. There are loads of such examples out there. There's nothing on
one app capturing another's output (that I've been able to find).
[quoted text, click to view] >
> "Neal Miller" wrote:
>
> > While there may be a more elegant way, you can just output the stack trace to a file or a database table, and have it read by the other app. Not optimal, I know, but you have a somewhat unusual design requirement.
> >
> > "jdmcfadden" wrote:
> >
DbgView (I'm pretty certain) is using the standard Windows API to capture the Debug events. This is cool and certainly doable in C#, but we were looking for a pure .NET solutuion. I gather from the anemic response and zero-discussion on the web, however, that one app can't capture another's TraceOutput using a listener. Bummer.
[quoted text, click to view] "Rob K" wrote:
> I wonder if, since DbgView is a freeware tool, the author of that
> program would be willing to share the technique(s) he uses in that
> program to capture those outputs? Can't imagine it would hurt to email
> him and ask.
>
>
>
>
> "jdmcfadden" <jimUNDERSCOREmcfaddenATcomcastDOTnet> wrote in message news:<EA112709-D41F-4AF3-A10E-411D33B5485B@microsoft.com>...
> > No, that won't work. The point is to have a real-time display of the
> OutputDebugString data, such as debuggers like DbgView provide. It's
> essentially a tool for the operations people to use to be able to just
> start, point to a given service, eyeball the output and say, "Yup,
> everything's fine". The designers do not consider logfiles realtime
> enough. There are loads of such examples out there. There's nothing on
> one app capturing another's output (that I've been able to find).
> >
> > "Neal Miller" wrote:
> >
> > > While there may be a more elegant way, you can just output the stack trace to a file or a database table, and have it read by the other app. Not optimal, I know, but you have a somewhat unusual design requirement.
> > >
> > > "jdmcfadden" wrote:
> > >
> > > > I have multiple C# apps that work together. For operational support, I'd like to be able to build an app that can capture the trace output of one or more of the applications, just like SysInternals' DbgView does (Just using DbgView itself is not an acceptable long-term solution by corporate decree). Is there anyway for Application A to capture the trace output of Application B
Don't see what you're looking for? Try a search.
