You are here

Home › Articles › C/C++

Buggy NoStepInto in VS.NET 7.0/7.1

NoSetpInto is very handy feature of VS.NET that is not documented. You can find the description in blog of Andy Pennell. I used this trick in Visual C++ 6.0. When I upgraded to VS.NET 7.1, I was dissapointed, the feature did not worked for me, but there were other users sucessfully using it.

I debugged the VS.NET debugger with VS.NET debugger, funny story. Here is what I discovered.

(posted to microsoft.public.dotnet.languages.vc, Feb 11, 2004)

I did some assembler hacking and I can tell where the problem (most probably) is:

The NatDbgDE.dll function CExecutionMap::LoadPatterns() loads the NoStepInto patterns. The function calls CDebugSession::GetRegistryRoot() to get the debugger registry root path. Inside this function I see that the output buffer is compared for NULL and also it's size is checked against size of the source string (9 + 0x23). But is seems that the size of output buffer is wrong (uninitialized), on my XP it happens to be a very big number, on my Win2k it happens to be 0. On Win2k the function returns fails because the buffer is too small, on XP the buffer is filled. The result of function is not checked and LoadPatterns() tries to RegOpenKeyEx() with whatever data happens to be in memory on Win2k...this function fails and the NoStepInto will not work.

I modified NatDbgDE.dll with "NOP" over the test for output buffer size and now the NoStepInto works fine.

Please pass this email to someone responsible for NatDbgDE.dll code.

Thanks, Jan

PS: I used VC 7.1 debugger and symbols from symbol server for the debugging

I got reply from Andy Pennell, Visual Studio Debugger Dev Leader:

I see you debugged the debugger and figured out what was up with NoStepInto! Great job.

I checked and the same bug exists in Whidbey, so I'll try to get that fixed. I added this info to my blog entry on the feature.

Andy Pennell, Visual Studio Debugger Dev Lead (see my blog http://blogs.msdn.com/andypennell/)