Min Kwan Park's bLog : About VS Debugger

Looking for VS Beta1 debugger issues?

mkpark — Thu, 29 Jul 2004 03:40:00 GMT

Probably, many of my co-workers are adding these kind of information into their blogs. but I decided to make my own list again. so if you want to see, check “Known debugger issues in VS8 Beta1” article.

While you do test your program...

mkpark — Wed, 14 Jul 2004 11:29:00 GMT

In most times, while I do dogfood/test VisualStudio 2005, I put them under debugger to monitor several things...

- First Chance AV

- Unhandled Exception

- Userbreaks from System to process under debugger

- Appverifier(a tool which is part of Application Compatibility Toolset) notification via Int3(User break)

*ACT is downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyID=7fc46855-b8a4-46cd-a236-3159970fde94&DisplayLang=en

If you are using debug build for testing, you don't have to run your app under debugger in most of cases because your debug build may have enough asserts to show errors in early stage.

However for many QAs, using retail build which will be shipped to customer is more general. so monitoring app with Debugger and appverifier is very interesting ways to do.

For example, I saw fair amount of issues that the thread by RPC call crashes and the AV caught by RPC handler. so caller may handle it without actual crash but it ends up as random and catastropic errors. however under debugger, you can see this kind of issues. so you can easily figure out the real cause of random issues.

Adding to this, with various Appverifier options, you can expose memory and handle issues much easier by reducing the tolerance of memory/handle mis-usages. it is really useful to improve overal stability of your product.

Are you looking for the latest edition of "The VS7 Debugger doesn’t work. What can I do?" document?

mkpark — Wed, 10 Mar 2004 02:04:00 GMT

Well, while we are moved to this weblog, the link of my document is just gone from gotdotnet. and I got many mails from people about whether the latest document is.

so I moved it on my weblog. it is live!!! whenever there is any new issues from customer, I updated it. so please enjoy it. if you want to get word format doc with pictures, please send me mail. I'll forward it to you.

the link is http://weblogs.asp.net/mkpark/articles/86872.aspx

Need to debug in both of Native and Managed together, but don't want to use InterOp mode debugging....

mkpark — Fri, 30 Jan 2004 11:09:00 GMT

VS7.x debugger has awesome feature which is known as InterOp, debugging managed and native codes together. it will let you step between different program types. so you can step from Native code to Manage and Manage to Native. also you can see mixed call stacks.

However, this feature is not flawless. it is slower than native only and managed only debugging. and in some cases, your native debugging is limited by InterOp mode debugging. but you still need to debug your process with both of them.

Well, I got this kind of situation some times and I was thinking how I can do this. and I figured out a way to do this. Normally VS7.x debugger checks whether there is any other debugger in place or not before starting debugging. so with general way, you will just get an error message.

But, if you start managed debugging first and attach to the process via MSVCMON for native debugging with other instance of debugger, you still can debug one process with two different debug modes(both of Native and Managed).

However when native debugger gets into break mode, because it is hard mode break your managed side debugger can't do any thing at all until you release the Native side debugger to get into run mode.

if you remember this, when your InterOp mode debugger doesn't fit into your situation, you still can do debugging in both way at same time.

Hope it help you.