C04622027.fm Page 151 Monday, October 9, 2006 10:34 AM Chapter 4 Common .NET Debugging Questions In this chapter: Process- and Infrastructure-Related Questions. .151 Visual Studio Bugs . .165 Designing for Debugging. .166 Debugger Questions . .170 Debugging Scenario Questions . .177 What Tools Do You Use? . .185 Summary . .195 The best part about writing books and articles, in addition to speaking at conferences, is get- ting the questions from developers about debugging and .NET in general. Although I do get a few “my application doesn’t run—what do I do?” e-mails, most of the questions are well thought out and make me look at areas of .NET I normally don’t get a chance to work with— it’s a great learning experience for me. In fact, I enjoy the questions so much I will feel lonely if I don’t get an e-mail question from each of you who purchase the book. Since the last edition of this book, I’ve been keeping a list of all the questions I’ve been asked, and I want to answer the most common of those. Obviously, many of them apply to debug- ging .NET applications, but having gotten many questions about other aspects of develop- ment, I wanted to answer those also. Because of the breadth and depth of .NET development, I may not answer your particular burning question in this chapter, but I can guarantee you’ll learn something. Process- and Infrastructure-Related Questions Many questions I’ve gotten are about debugging and process-related issues. Although I’ve done my best to make Chapter 1, “Bugs: Where They Come From and How You Solve Them,” and Chapter 2, “Preparing for Debugging,” which discussed those issues, as complete as pos- sible, I still get many questions about those issues. Additionally, some common questions are even about the nature of using computers. 151 C04622027.fm Page 152 Monday, October 9, 2006 10:34 AM 152 Part I The Gestalt of Debugging Why must you always develop as a non-admin? If you are logging on to your computer using an account with administrator privileges, you need to raise your right hand and repeat after me: “I do solemnly swear that by the time I get to the end of this question’s answer, I will put this book down and immediately correct the sit- uation. Additionally, I will make all my coworkers do the same.” There is absolutely no reason at all for logging in with administrator rights to develop software! The only time you need to use an account with administrator rights is if you are debugging across user accounts. Fortunately, it’s easy to start individual processes with greater rights so you can do the debugging. One of the most important features of Microsoft Windows Vista is User Account Control (UAC), which defaults users to less privileged accounts and prompts for required credentials whenever a process tries to do something that needs higher privileges. Even with the release of Windows Vista imminent, we will realistically be developing on and using Microsoft Win- dows XP and Microsoft Windows Server 2003 for many years before we have most of our development teams using the new operating system. That doesn’t even consider the end-user or corporate-user scenario, which will take even longer to migrate over. The most important reason you need to be developing without administrator rights, in other words using a limited user account, is to ensure that your application works correctly on a less privileged account. As someone who’s been developing as a limited user for years, it’s hugely frustrating to run an application and see it crash or have an unhandled exception because the developers assumed that everyone runs with administrator rights. This is a completely preventable bug that tells the user that the developers are lazy and certainly aren’t doing their job. The good news is that on Windows XP and Windows Server 2003, it’s easy to find all the tricks because there’s now an excellent Web site that will get you started: Jonathan Hardwick’s http://nonadmin.editme.com. Many of the links and articles on the Web site point to Aaron Margosis’s blog (http://blogs.msdn.com/aaron_margosis)—he’s done the best writing on the subject. Both Web sites are excellent and are part of your required reading. The main idea behind using your computer without administrator rights is that you’ll use the Runas.exe program that comes with Windows to start particular processes as a user with administrator rights on that machine. For example, if you wanted to debug a Microsoft ASP.NET application running inside Internet Information Services (IIS), the debugger would need administrator rights to debug across the user accounts (your account to Local Service), so you would run the following command (assuming that Microsoft Visual Studio is in the path and the account you want to use is Administrator): runas /u:Administrator devenv.exe The runas command will prompt you for the Administrator account password, and after you type it, Visual Studio will start. From the new instance of Visual Studio, you can now debug the IIS-based application without exposing your whole system to viruses and spyware C04622027.fm Page 153 Monday, October 9, 2006 10:34 AM Chapter 4 Common .NET Debugging Questions 153 because you logged in as an administrator. Note that you can also use Mark Russinovich’s excellent Psexec.exe program (http://www.sysinternals.com/Utilities/PsExec.html), which even allows you to start programs on other machines. The last thing I want to mention about runas is that when you start a program with it, the pro- gram is using the profile from a different user, not the logged-in user. You probably already guessed that, but I’ve seen people get tripped up with setting an environment variable in their logged in account and wonder why their program started with runas doesn’t see the environ- ment variable. If you’re still not convinced that running with a non-administrator account is worthwhile, you should read the wonderful study done by Andrew Garcia in the magazine eWeek, “Is System Lockdown the Secret Weapon?” (http://www.eweek.com/article2/0,1759,1891447,00.asp). He took two fully patched systems, one running Microsoft Windows 2000 Professional SP4 and the other running Windows XP Professional SP2, and surfed some not-so-good Web sites using Administrator, Power User, and User accounts. After each surfing session, he ran spy- ware scans. On Windows XP, the Administrator and Power User accounts had 16 total threats! In setting up my friends’ and family members’ machines so they all run as a limited user, I’ve eliminated nearly all the spyware and virus calls I used to get. The http://nonadmin.editme.com site does a great job of getting you started, but I wanted to share some of my tips about running and developing in a limited user account to help you make the transition. The Runas program is great from the command line, but there’s a hidden feature with shortcuts (.lnk files) that I like to use to automatically be prompted for the user account to run in when clicking the shortcut. After you’ve created the .lnk file, right-click its icon and select Properties from the shortcut menu. On the Shortcut tab, click Advanced to open the Advanced Properties dialog box. If you select the first check box, Run With Different Credentials, now whenever you double-click the shortcut, you’ll be prompted with the Run As dialog box, shown in Figure 4-1, in which you can specify the user name and password to run the application. Figure 4-1 Shortcut prompt for user account C04622027.fm Page 154 Monday, October 9, 2006 10:34 AM 154 Part I The Gestalt of Debugging This is a very convenient way to start applications such as Visual Studio. However, there seems to be a bug in saving the shortcut, because if you change other values in the .lnk file properties, Windows Explorer randomly forgets that you selected the Run With Different Cre- dentials check box. To work around this bug, make all the other changes to the shortcut and save those changes. Go back into the Properties dialog box for the shortcut and select the Run With Different Credentials check box as the last change. One shortcut I like to set up with Run With Different Credentials is one to a Command Prompt. If the Command Prompt is running with administrator privileges, any applications you start from it are also under the same account. If you need to run multiple items with administrator privileges, this trick is very convenient. I even change the icon for that link to be a pirate skull and bones so it appears when pressing Alt+Tab thus helping me find it quickly. When logged on with limited privileges, you sometimes need to access to Windows Explorer to set security on a directory or set up a share. To allow you to run Windows Explorer for another account, you’ll first need to log on to that account and then set Windows Explorer to use separate instances. On the Tools menu, select Folder Options, click the View tab, and in the Advanced Settings box, scroll down and select the Launch Folder Windows In A Separate Process check box. It is a very good idea to enable this setting in general because each Explorer window is in a separate process—if one hangs, you don’t hang the desktop, the taskbar, and everything else on the machine.