MSCOM OPS March Debug Madness…2nd Session Q & A Debugging CLR Internals

Tuesday we jumped into Debugging CLR Internals (which is now avaiable on-demand) and presented by Jeff Stucky, the Systems Engineer Manager of the MSCOM OPS Debugging Team. The folks that attended asked some outstanding questions…

1. Asked: is the inclusion of a try catch block bad for the performance of an app even though an exception rarely occurs?
Answered: This is absolutely not a bad thing to do for developers. However, you do not want to use exception handling to control the flow of your application…ever. They are for exceptional situations only. If you are running your application and seeing any exceptions being thrown at all during “normal” load, then you have a problem.

2. Asked: Can you post or point us to that cool little tinyget5 utility?
Answered: Tinyget5 is the internal name for tinyget.exe which is available as part of the IIS 6 Resource Kit.

3. Asked: Any download link for the cdb.exe?
Answered: It is part of the Windows Debugger package available from https://www.microsoft.com/whdc/devtools/debugging/default.mspx

4. Asked: Using Perfmon right now to add the counters he specified. I'd like the graph scale on these counters to be "1", not "0.1" . It's been years since I used Perfmon, is there a way to do this?
Answered: If you right click on the counter and choose properties, the window will pop up and give a few choices, including Scale.

5. Asked: Jeff seems to be running a 64-bit system. I assume he's using a virtualization engine and also has 32-bit Windows installed. Just out of curiosity, about how much slower would that tinyget demo (5000 redirects, as I recall) take on a 32-bit system? (Demo times were running 5-6 seconds in 64-bit mode).
Answered: Actually, he is running on a native 64-bit system. This particular demo is not all that memory or processor intensive, so time should be roughly the same, depending on whether the hardware is equivalent. For exceptions, they will have higher overhead on 64-bit systems, for several reasons including exception handling behavior on x64.

6. Asked: Why does response.redirect get logged as an exception?
Answered: If the 2nd param to Response.Redirect() is not false, it aborts the request after sending the redirect - causing the thead abort exception. We recommend using FALSE as 2nd param if possible.

7. Asked: Any situations where we would want the thread abort exception? I mean why not set the default to NOT throw the thread abort exception? Which is basically a Response.End right?
Answered: Depending on the flow of your code, You may not want your code to continue to running after a Response.Redirect(). By using FALSE it will continue to run after the Redirect. Yes, it basically ends up calling Response.End, which we like to avoid for the same rason, ThreadAbort Exceptions.

8. Asked: Are there situations where this exception will not be thrown? Like if it is the last execution line?
Answered: I believe the Thread abort exception is thrown regardless. If it is the last execution line it is a great candidate for passing the FALSE param.

9. Asked: Sorry if this is off topic. What is the "Check if file exists" option in IIS used for?
Answered: Yep, off topic... but I know the answer. Check If File Exists forces IIS to verify that the file request does in fact exist on the disk BEFORE handing the request off to the ISAPI Extension that it is mapped to.

10. Asked: I dont think I followed that.. what he said was if an exception occurred in 2.0 and it bubbled up to the app, the worker process would be killed?
Answered: Prior to ASP.NET 2.0, an unhandled exception in the framework would *not* terminate the IIS worker process. A change was implemented where now that unhandled exception will cause the IIS Worker Process (W3WP.exe) to terminate potentially killing other well-behaving applications. They used a legacy switch to change the behavior away from doing this (i.e. killing IIS worker process)

11. Asked: Where can we find recycleap.vbs (as used in this demo), it sounds like a good tool?
Answered: The tool is basically just a script wrapper for making WMI calls to IIS. IISAPP.VBS now contains a lot of the functionality of recycleap for recycling app pools. I'll see about getting an example script posted to our blog site

12. Asked: Will the shutting down of the worker process be changed in the SP1 for .NET 2.0 framework if an unhandled exception is thrown?
Answered: I dont know of any plans to change this. You can revert back to the Everett behavior currently with the legacyUnhandledExceptionPolicy config setting.

13. Asked: What is iisapp which was used to associate PID with App domain?
Answered: %windir%\system32\iisapp.vbs is a script provided by the IIS team to allow mapping of AppPools to Process IDs. iisapp.vbs /? contains useful help information

14. Asked: Is 4 the maximum number of GC Threads in a multiprocessor system? Can this be changed back to a single thread? Also how about the priority of these thread? Possibility to deadlocks? I assume there is a timeout of about 2 secs per collection?
Answered: You actually get 1 GC thread per processor per process with the CLR framework loaded. So on a single processor machine you do only get 1 thread. The possibility of deadlock has hopefully been eliminated (though there is always the chance for a bug in any software project).

15. Asked: Hi jef When you explained ASP.NET Caching may drive CPU to 100% are you talking about the OutputCache directive ?
Answered: Certainly OutputCache can help drive memory use, but I was referring more to using the Cache class from System.Web.Caching. More specifically, caching items that are not hot and caching items with no expiration policy.

16. Asked: So assuming that you have 1 multicore cpu there will be 2 GC threads and 2 seperate heaps?
Answered: You will have 1 thread per CPU as seen by the OS. In other words, if Task Manager shows you 2 CPUs, you will have 2 GC threads per process.

17. Asked: I apologize for asking such an extremely naive question, but how can the techniques Jeff's demonstrating be used when debugging Windows Mobile apps? Are there Mobile versions of these tools?
Answered: They have those tools located at the MSDN .NET 2.0 SDK (Mobile is listed)

18. Asked: Do try..finally blocks (without catch) have the same high overhead as try...catch?
Answered: Generally yes. An exception is still thrown and the exception handling activity, such as stack unwinding, still occurs.

19. Asked: On a system with many worker processes Workstation GC is recommended, are we talking about concurrent or non-concurrent GC then?
Answered: When you set gcServer enabled = “false”, asp.net handles the gcconcurrent setting.

20. Comment: I loved it! Thx guys and thx Jeff! :)

21. Asked: Really good list of resources - thanks! Does anyone know if Richter's updating his book?
Answered: Yes, he's got a CLR via C# book that just came out

22. Asked: Will this meeting be available for later reviewing?
Answered: You bet...check our blog site https://blogs.technet.com/mscom...we will be posting all the questions with answers and links to the On-demand links once we get them

23. Asked: How many ASP Net applications do you typically host in a App Pool or single worker process?
Answered: We segregate our applications into a bunch of different App Pools based on varied criteria. For instance, for applications that absolutely have to be available, we’ll put them in their own app pool. For applications that are known to be unstable, we’ll lump those together in their own “untrusted” app pool. We also segments some applications geographically, so a particular country or region may have their own app pool. All in all, we have about a 50/50 mix of single app apppools vs multi app apppools. The multiapp pools can have upwards of 100 applications in them.

24. Asked: https://www.microsoft.com/mspress/books/5822.asp
Answered: https://www.microsoft.com/mspress/books/5822.asp

25. Asked: I encountered a problem with debugging codes containing Control.Invoke. Can I ask this question here or should I ask in the blogs?
Answered: We’ll try to answer on the blog if you ask there.

26. Asked: I've seen ILDASM and Windg, but nothing for IL to Native.
Answered: If your interested in understanding how IL related to native assembly, you could use the debugger to dump out the assembly for the function you’re interested in and compare against the IL for that function. Use !sos.name2ee <modulename>!<functionname> to get the JITTED Code Address and then run !sos.u against the address to get a full dump of the assembly for that function

27. Asked: Does WinDbg give you better debugging facilities for managed code than Visual Studio?
Answered: It is less a matter of better debugging facilities and more a matter of what you have available and the style of debugging you want to do. For our purposes we don't have Visual Studio installed on machines which can access our production machines so we tend to use WinDBG or CDB. However when we are trying to understand a specific api or set of functionality we often use Visual Studio on our development machines.

28. Asked: is the config entry for gc collection = true also made also made in machine.config or just in aspnet(.config) worker processes only?
Answered: Just aspnet.config

29. Asked: Is it possible to debug CLR which is in another machine?
Answered: Only through remote debugging, either with the standard debug package tools (windbg/cdb) or through visual studio. We don’t use VS for our production debugging needs.