.NET announced... PDC 2000
A co-worker of mine attended PDC 2000 and was blown away with what Microsoft had coming in the Visual Studio .NET lineup.
I found a some notes from the PDC 2000 by Chris Maunder of CodeProject.com Luckily I had been playing with eariler versions of .NET and was amazed by the power of ASP+ (ASP.NET). I creates some sites, toyed with post-backs and was amazed at ADO.NET for database access.
On to Betas.. and Beta Support
My love of .NET was no secret in product support, so when there was an opening in the Beta Support team for Visual Studio .NET, I jumped at the chance to work with this pre-release product.
While on the Beta support team, I supported customers and filed bugs in order to make a better product come RTM. Coming from a native debugging WinDNA debugging background, I was always looking for supportability enhancements that could be made to make the .NET Framework more supportable within production environments.
Since I was new to the product and the Beta Support team, I had to keep an open mind about the tools that we would use to debug .NET applications. The tools that I was investigating were:
- Visual Studio .NET
- DBGClr
- CORDBG
- WinDbg/CDB/NTSD w/ strike.dll
Visual Studio .NET
The Visual Studio .NET is the best debugger to use when developing applications. The watches, evaluations, and other debugger windows make it easy to track down bugs in assemblies that you have source code for. Once the application moved into the stress / staging environment, it becomes difficult to install a full version of Visual Studio .NET for debugging purposes.
DbgClr
DBGClr is installed with the .NET Framework SDK. The user interface is very similar to the Visual Studio .NET debugger with a few limitations. DBGClr only debugs managed code, and there is no remote debugging capability. Another big difference is that DbgClr is that there is no compiler included. In order to compile in the SDK you need to use the command line compilers like CSC.EXE and VBC.EXE.
CORDBG
I noticed that the .NET Framework SDK was shipping with a console based debugger called CORDBG. CORDBG was a sample debugger that was provided as an example of how a developer could use the ICordbg interface from native C++ code. One nice thing about CORDBG is that it can perform basic source level debugging (step into, step over, show source, locals etc.) and has an extremely light footprint. (3 files in addition to CORDBG.EXE) Unfortunately, the command syntax is different than the native debuggers that I was used to.
One handy command in CORDBG is the command * where. This command will dump the managed call stacks for all threads in the process. Also CORDBG has the ability to "detach" from a managed process and let the process continue as if it was never debugged.
WINDBG/CDB/NTSD w/ strike.dll (now SOS.dll)
While on the Visual Studio .NET beta I was tasked with debugging some stress related bugs in the CLR. Some of them were production managed memory issues. At the time, the only way to debug these issues was using WinDbg and strike.dll. Jason Zander goes into the history of the name strike (and soon Son of Strike) in his blog post. Look for the word "Lighting" right under his reference to the PAG Guide for Debugging. Our team investigated strike.dll and then worked with Jason Zander's CLR team to create and test SOS.dll.
SOS.dll was first released in the Production Debugging for .NET Applications whitepaper in a set of download tools. SOS.dll now ships with the .NET Framework 1.1 and 2.0 in the \Framework\<version>\ directory. The Debugging tools for Windows download ships the latest version of SOS.dll that works on 1.0 and 1.1 versions of the .NET Framework in the \clr10 directory.
WinDNA... My Love of Debugging Continues
The term WinDNA was used to describe the architecture of applications that utilized the latest Microsoft technologies of the time. The time was approximately 1998 and WinDNA stood for Windows Distributed interNet Application architecture. Windows 2000 was just shipping along with IIS 5.0 and COM+. Also customers started building applications on Commerce Server 2000 and SQL Server using Active Server Pages (ASP) and COM/COM+/DCOM. Most customers wrote Visual Basic 6.0 COM components though there were some components written in C++ ActiveX Template Library (ATL).
First you build it.. Then you deploy it.. Then you debug it.
When troubleshooting WinDNA applications, I found that I was executing the same debugging steps and asking the same questions over and over. One customer that I was working with wanted to know how I did what I did and whether I could package that information for others to learn as well. As a result, I presented and recorded the following video about Support WebCast: Debugging Windows DNA-based E-commerce Applications. A co-worker created a document that walks through Debugging Windows 2000 Web Applications which was a useful guide at the time.
Tools for the times...
As mentioned in the support web cast, the types of tools that were used depended on the problem at hand. There were three buckets of problems.
They were:
- Crashes (Errors like ASP 0115)
- Hangs (Non-responsive web servers or applications)
- Resource issues (Memory Leaks or CPU Spikes)
In order to troubleshoot these scenarios, the tools used were:
- Exception Monitor 7.0
- UserDump
- Performance Monitor / UserDump / Exception Monitor etc.
ADPlus was born...
In time, Exception Monitor and UserDump were replaced with a new tool called AutoDump+ (ADPlus). The etymology for the name ADPlus came from a script that a co-worker wrote called AutoDump.vbs. I believe that this script looked for the IIS and COM+ related processes and created full process dumps for them. The tool was greatly enhanced to have -crash and -hang modes along with a number of additional features and capabilities. Keeping with the convention that the next version a product was the product name with "+" appended, the name ADPlus was chosen.
Eventually, the WinDBG team included ADPlus.vbs in the publically available Debuggers package and customers were able to download and run it to resolve support issues.
[Next I will blog about the PDC 2000 and the introduction to the .NET Framework and ASP.NET]
Automating Debugging Sessions with Exception Monitor
While performing live debug sessions I noticed that CDB.EXE had a feature that would allow a list of commands to be executed. The trick was to put a file called NTSD.INI in the same directory as the debugger and the debugger would automatically run the commands in the file on start-up.
I also noticed that customers were not as comfortable running a series of batch files on their production servers as a tool that had a user interface and looked more official. So one day I had an idea. My idea was to create a wizard that would walk a customer through a debugging session. If you had a "hang" then you go down one path, if you had a "crash", then you went down another path
The tool ended up being called the "IIS Exception Monitor". The IIS Support team used this tool to list out the exceptions that were happening in a process and dump the call stacks. This was the first stage of automating the debugging process.
For nostagic reasons you may want to see the article that I wrote on the IIS Exception Monitor that was updated in August 2000.
Introduction
I have worked for Microsoft for over 10 years. I started in Windows supporting Windows NT 3.51 and then did a brief stint in SNA Server until shortly after the SNA Server 3.0 launch.
My introduction to the WWW.. and IIS
While on the SNA team I was exposed to IIS 1.0 beta. This was my first beta as a Microsoft employee. You see, while I was in college I worked with Windows NT 3.5 Server and I the Windows NT Resource Kit came with a web server called EMWACS Web Server. This was a simple web server that had a Control Panel interface and an option to determine where you wanted your content placed. I started writing very simple web pages and was hooked on HTTP and the World Wide Web.
When I found out that Microsoft was writing an web server, I jumped at the chance to learn more about it. At the time CGI was the only way to make web servers do anything interesting, and CGIs were usually written in PERL or C++. IIS brought ISAPIs to the table, and I was anxious to learn the power of ISAPI DLLs. The first one I started working with was called HTTPODBC.dll.
On to Dynamic web pages...
While on the SNA Server support team, I worked with HTTPODBC and soon started taking IIS cases and solving HTTPODBC issues for customers. My natural progression was toward the IIS support team so I applied and joined the small team of IIS Support engineers.
Playing in the same sandbox..
While on the IIS support team, I noticed a common pattern with issues. Customers would call in with a server that created a dr watson or was hung and then would want to know what the problem was. Time after time, the issue was determined to be within ISAPI code that was "plugged in" to the IIS framework. The disadvantage was that if there was a problem with ISAPI dlls then they took down the entire INETINFO.EXE process... and then the phone rang.
My introduction to debugging..
When our customers had a "server down" I learned very quickly that you do all that is in your power to solve the issue at hand. The more seasoned engineers and the development teams for Microsoft's products used a tool called CDB to perform their debugging. This tool had an arcane syntax that has become more and more accepted with the hard-core technical community over the years.
The idea was that you connect to a process, examine callstacks for running threads and if your symbols line up, you may find something interesting. The trick was getting your symbols to line up. If they didn't, then the debug session would be of little use and you might as well be trying to solve the issue by throwing darts at a dart board.
On to remote debugging...
Sometimes you needed development to "remote" into your CDB session. Back then this was accomplished with a Resource Kit utility called REMOTE.EXE. You would run REMOTE.EXE /s cmd "sessionname" on the debuggee and then run REMOTE.EXE /c SERVER-NAME "sessionname" on the remote client to connect in and perform your debugging. Things haven't changed that much since then.
[more of this later...]
