You are here

Domů › Články › C/C++

Chyba v NoStepInto nastavení VS.NET 7.1

NoStepInto je velmi šikovná nedokumentovaná vlastnost při ladění aplikací. Její popis můžete najít třeba na blogu Andy Pennella. Dost jsem si na její použití zvykl ve verzi Visual C++ 6.0. Při přechodu na verzi VS.NET 7.1 jsem byl velmi rozladěn tím, že to nefunguje, i když by podle všeho mělo.

Tak jsem se pustil do ladění VS.NET debuggeru pomocí VS.NET debuggeru. Na co jsem přišel si můžete přečíst v následující korespondenci.

(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

Dostal jsem odpověď přímo od Andyho Pennella, vedoucího týmu vývoje debuggeru:

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/)