Geeks With Blogs

Charles Young
Like most BizTalk Server developers I am addicted to the use of DebugView.   This, in case you are one of the three BizTalk developers out there who are still not aware of it, is a free utility written by the SysInternals people.   Microsoft bought SysInternals a while back, and the utility can now be downloaded from their web site at:
DebugView provides a viewer for traces created using the Win32 OutputDebugString() API. You can liberally instrument your .NET code using calls to System.Diagnostics.Debug.Write<xxx> methods, then open up DebugView and run you code.   The output is nicely displayed in the DebugView console. For BizTalk developers, this is an indispensable tool because there is no way to single-step through XLANG/s expressions.   The Orchestration debugger is built on top of the orchestration engine, and is not a 'true' Win32 debugger.   It can only single-step through interactions between the orchestration and the orchestration engine which occur at a much coarser level of granularity than individual lines of XLANG/s code.
I've spent the last couple of weeks pretending to be an ASP.NET 2.0 developer.   The code I was writing does a fair amount of re-direction.   It supports a number of different log-in models based on the Forms Authentication model in ASP.NET 2.0, but integrated with a remote identity provider.   The code is 'proof of concept' stuff, and supports different ‘candidate’ approaches, including the ability to switch to local authentication in order to demonstrate the code in scenarios where we have no remote connectivity.   To begin with I (rather stupidly, in hindsight) was trying to develop using the new Web Site project type in Visual Studio.   Oh dear.   I needed to use SSL sessions to debug the code because we are using CardSpace.   You can't do this under the local web server.   I tried, without success, to debug my code under IIS, but found that, for some reason, I was unable to attach to IIS worker processes!   Then, I really came unstuck when ASP.NET completely lost the ability to debug.   It was creating pdb files OK, but one of them appeared to be corrupted somehow each time it was built (for example, no version number), and Visual Studio insisted that I had no symbols loaded, even though the Module window clearly showed that I did!
I gave up, and ported the code over to a Web Application project.   I still have problems.   Visual Studio currently reports a set of spurious build errors 'dynamically' while using the designer (these change dynamically over time even if I don't touch the keyboard - yes I mean it! I just sit there and stare at the screen for a minute or two and see the error messages change before my eyes), but then builds and publishes the application anyway.   It has lost the ability to see Master Pages if I use generated paths with the '~' specifier. It has also become hopelessly confused in regard to a custom control that I am using - a problem, incidentally, for which there are hundreds of hits in Google, but only one conclusion - 'tough - it's a long-standing bug - you can't fix it and there's no known workaround - rebuild your project from scratch'.   Apart from that, the Web Application works OK, and I can now debug my code smoothly under SSL sessions.   A good lesson learned.   I certainly won't use Web Site projects in future, and will try not to use ASP.NET unless I have to, until such time as Microsoft sees fit to stabilise the design-time ASP.NET tools.
[Update: I had another go at clearing the persistent "Unknown server tag" problem, which is the issue I reported above with the custom control.   I tried (yet again) a whole variety of approaches, including registering the control via the web.config file, rather than using the @Register directive.   I eventually hit on an approach which seemed to work.   I recompiled the control using a strong name.   I had tried this before, but when I GACd the assembly, I got a new error in which ASP.NET reported confusion at runtime over having two copies of the assembly (one in the ASP.NET TEMP folders and one in the GAC).   So this time, having encountered the same problem, I simply removed the control from the GAC (duh).   And suddenly I can use the control in the designer again!   As far as I am aware, this is the only change I have made (of course, you have to update the assembly name in the @Register directive to the strong name).   I note that Visual Studio automatically updates an assembly reference for the control in the web.config file.   Of course, everything was originally working fine for some time with a simple-named version of the same control (I haven't changed the control code in any way), so I fully expect everything to break down again for no apparant reason].
[Update 2: Oh yes.  As predicted.   Within an hour or two the designer magically lost its ability to handle my strongly-named version of the control.   How do ASP.NET developers cope with this day in, day out?]
The point of this, apart from letting off steam about the general flakiness of ASP.NET 2.0 under Visual Studio 2005 SP1 (it's horrible), is that while developing using the Web Site, I needed to use DebugView quite extensively.   Even now, it is of some use due to the re-direction.   I can trace my code in one page, even though this page redirects to another so that I can't see my trace output using the built-in tracing features of ASP.NET.   DebugView shows me what I need to see, as long as I remember to place '#define DEBUG' statements in my 'CodeBehind' files.
I ran into a problem with DebugView which I have seen before.   I've been trying to research it to come up with a definitive answer, but I don't know the underlying cause - just the symptoms.   My problem is that my ASP.NET code runs in a different session to the desktop.   This means that the output does not appear in DebugView unless I enable the 'Capture Global Win32' option.   However, this option was not available in DebugView.
At this point, I should say that I am developing on Windows Server 2003 R2.   I run Vista on my notebook.   When I open the same version of DebugView on my Vista notebook, I can see the 'Capture Global Win32' option.   However, I can't see it when I run DebugView on the Windows Server 2003 box.
I was tearing my hair out over this one, and it isn't the first time I have run into this problem.   I spent some time trying to find an answer on Google.   I didn't turn anything up, but somewhere I read something about remote connections.   I had a thought.   I powered up a Remote Desktop session to my own development box and then opened DebugView.   Success!   The 'Capture Global Win32' option appeared, and once selected, DebugView started happily displaying the output from my ASP.NET application.
This approach cannot be used on XP (or, I think, Vista) because, even with SP2, XP does not support concurrent remote desktop sessions.   Apparently, Microsoft was going to lift this restriction at some point, but then decided not to.   As I say, when running DebugView under Vista, I don't get the problem anyway.
I experimented further with DebugView by setting up a 'client' instance (surely this should be termed a 'server' instance') and then connecting to this on the same machine.   In my first attempt, this appeared to work, but when I tried to reproduce the approach the following day, it failed.   The Remote Desktop approach works every time though.
As I say, I don't currently have an explanation.   I know, from Googling, that there are some interesting issues when using OutputDebugString regarding the permission set granted to an underlying Mutex.   Maybe the behaviour of DebugView has something to do with this.   Maybe the explanation is simpler.   It may have something to do with having another registered debugger in the same Windows session.   I'm not sure.   What I do know is that remoting into your own desktop on Windows Server 2003 works very nicely indeed.
Posted on Sunday, September 16, 2007 2:24 PM BizTalk Server 2004/2006 | Back to top

Comments on this post: DebugView and the elusive 'Capture Global Win32' option

# re: DebugView and the elusive 'Capture Global Win32' option
Requesting Gravatar...
thanks for your article. I have a lot of experience in using a remote desktop on Win 2k3. For my job it's the best operating system. With Win NT or XP I had many problems which weren't able to solve.

Best regards,
Left by Bayer on Mar 07, 2008 4:31 PM

# re: DebugView and the elusive 'Capture Global Win32' option
Requesting Gravatar...

Funny, I just went through exactly what you did :)

I wanted my WCF service to echo out to DebugView.

There's an easier way to do it (thankfully!):

- enable debugging by setting "compilation debug=true" in the Web.config
- instead of using System.Diagnostics.Trace.Write..., use System.Diagnostics.Debug.Write....

And.... voila, I see text now!

Left by Brian Loesgen on Mar 18, 2008 9:33 PM

Your comment:
 (will show your gravatar)

Copyright © Charles Young | Powered by: