Posts Tagged ‘debugging’VS.NET2003, Windows Vista & Remote DebuggingThursday, March 22nd, 2007If you’re like me you will have a development machine that’s got a bit of power behind it. You might also be a bit keen on new technology. You may have even gone ahead and installed Windows Vista thinking – she’ll be right. If you’re still like me at this point you’ll be thinking “bugger”. Visual Studio.NET 2003 is not supported on Vista = but it does work for the most part. The big issue is web development. What has worked for me, and may well work for you, is installing Windows XP on Virtual PC 2007 (free). I put my web sites on the XP VPC and I can still run the IDE on Vista. While this is a little clunky everything seems to work pretty well. Then one day… bang! The debugger refused to attach. Checking the event logs I found a very unhelpful Event ID 10023: “The application-specific access security descriptor for the COM Server application C:\Program Files\Common Files\Microsoft Shared\VS7Debug\mdm.exe is invalid. It contains Access Control Entries with permissions that are invalid. The requested action was therefore not performed. The application set this security permission programmatically; to modify this security permission contact the application vendor.” I have no idea what happened from one minute to the next but it was properly busted. I tried a million things including every known remote debugging setup check. I even reinstalled VS.NET 2003 & VS2005. The thing that eventually did the trick was:
I suspect there was another issue, and in trying to solve it I had added domain accounts to the DCOM config of Machine Debug Manager in “Access Permissions”. Further testing has revealed that this is what has killed it. If you are having this problem now you know why
Debugging TipsWednesday, February 28th, 2007The number one problem I find when I help someone debug a problem is the assumptions that have been made. If you’re running a program and it doesn’t behave the way you expect it to what are you going to do? “Step through the code to see what’s going wrong” you say? Chances are that will only help you if you’ve done something obvious, like a typo or a missing bracket. Besides which there are lots of times when stepping through code is impractical or just not possible, such as when the problem is in a CSS style expression. Debugging these is a downright pain. The first thing you should do after the obvious leads are exhausted is to CHALLENGE YOUR ASSUMPTIONS! (Yes I’m shouting it.) I can’t stress this enough – back to the aforementioned CSS style, what kind of assumptions have we made:
Simple questions to answer but do ask them. A lot of the time you’ll notice that you aren’t where you think you are – which explains why you’re going the wrong way. Get used to using Debug.Assert()If you don’t use this gem of a method you’re only slowing yourself down. This comes right back to challenging your assumptions. The Assert() method allows you to add a test expression and a message into your code – when the test fails the message is displayed. The beautiful thing is you can leave them all over the place, because when you compile for Release the compiler leaves them all out. You should include one of these whenever you make an assumption in code – because we can’t always remember our own rules, and sometimes we’re not the only ones using our code. For example, I recently had a problem with a form’s progress meter not displaying properly – I never got any value from it. I added a Debug.Asset() to check the value of pb.Maximum – surely the maximum value was not set to 0 – it should be the record count from a record set I had just loaded. Oh no… turns out the call to set the maximum and the call to load the records were in the wrong order. The Assert pulled me right up. This gets even better when you’re programming in a multi-threaded environment, because the act of debugging interferes with the way the threads behave, since you artificially slow down the execution. Debugger.Launch() & Debugger.Break()Two more little gems, these. Quite often people ask on news groups and the like “how do I debug a Windows Process”? EASY! In your Start() method simply add: Debugger.Launch(); Debugger.Break(); When the run-time hits the first line it will pause processing and prompt you to attach a debugger. The second line is a programmatic break point (which you don’t officially need but the Launch() breaks you into the Dissassembler instead of the code). If you’re a web programmer you may already know about… Javascript: debuggerThis works the same way as Debugger.Launch() but for Javascript – perfect for debugging web pages! It is a statement, not a method, so to use it simply put in the line: debugger; and you’re done.
|
ArchivesTag Cloud |
For some reason simply removing the offending accounts doesn’t help you have to perform the steps above.