Visual Studio 2008 Debugging Weirdness
-
New PC to set today. I installed VS2008 (because that's what we use here), SP1, a security update or two. But, whenever I try to debug a C++ app the IDE pauses a second or two every time I step to the next line. I've tried closing the Auto, Local, Threads windows. I've tried all the obvious options in Tools / Options / Debugging. I've told the AV crap to ignore devenv.exe. No difference. And, this happens even in the simplest native C++ app. It's not related to project size. So, I opened up ProcMon, aimed it at devenv.exe and stepped to the next a line of code in the debugger... and here's where it gets weird. After a bunch of Registry calls into the MS/Cryptography stuff (?), the IDE starts looking at the source file I'm debugging. Let's call it "c:\dev\foo\bar\mysrc.c". ProcMon shows a CreateFile call on "C:\", a QueryDirectory on "C:\dev" then a CloseFile on "C:\". Then a CreateFile call on "C:\dev", a QueryDirectory on "C:\dev\foo\" then a CloseFile on "C:\dev". Then a CreateFile call on "C:\dev\foo", a QueryDirectory on "C:\dev\foo\bar" then a CloseFile on "C:\dev\foo". Then a CreateFile call on "C:\dev\foo\bar", a QueryDirectory on "C:\dev\foo\bar\mysrc.c" then a CloseFile on "C:\dev\foo\bar". Then a QueryBasicInformationFile call on "C:\dev\foo\bar\mysrc.c". OK, it's looking at the source file and testing all the subdirs on the way down. Inefficient, but OK. BUT THEN (!!!)... it does this: CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\dev\foo\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\foo\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\mysrc.c" all these end up with "path not found", obviously. AND THEN (!!!) it does the same thing in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\" - and all of the sub paths, again. And then in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\src\atl\". And then in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\". And then... etc... Through all of the MFC, ATL, source and include folders, all of the SDK source and include folders. And then, just for good measure, it repeats the first scan (leading to the actual file), ending with a QueryNetworkOpenInformationFile call on the source file. So, by the end of all this, there are hundreds a
-
New PC to set today. I installed VS2008 (because that's what we use here), SP1, a security update or two. But, whenever I try to debug a C++ app the IDE pauses a second or two every time I step to the next line. I've tried closing the Auto, Local, Threads windows. I've tried all the obvious options in Tools / Options / Debugging. I've told the AV crap to ignore devenv.exe. No difference. And, this happens even in the simplest native C++ app. It's not related to project size. So, I opened up ProcMon, aimed it at devenv.exe and stepped to the next a line of code in the debugger... and here's where it gets weird. After a bunch of Registry calls into the MS/Cryptography stuff (?), the IDE starts looking at the source file I'm debugging. Let's call it "c:\dev\foo\bar\mysrc.c". ProcMon shows a CreateFile call on "C:\", a QueryDirectory on "C:\dev" then a CloseFile on "C:\". Then a CreateFile call on "C:\dev", a QueryDirectory on "C:\dev\foo\" then a CloseFile on "C:\dev". Then a CreateFile call on "C:\dev\foo", a QueryDirectory on "C:\dev\foo\bar" then a CloseFile on "C:\dev\foo". Then a CreateFile call on "C:\dev\foo\bar", a QueryDirectory on "C:\dev\foo\bar\mysrc.c" then a CloseFile on "C:\dev\foo\bar". Then a QueryBasicInformationFile call on "C:\dev\foo\bar\mysrc.c". OK, it's looking at the source file and testing all the subdirs on the way down. Inefficient, but OK. BUT THEN (!!!)... it does this: CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\dev\foo\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\foo\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\mysrc.c" all these end up with "path not found", obviously. AND THEN (!!!) it does the same thing in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\" - and all of the sub paths, again. And then in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\src\atl\". And then in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\". And then... etc... Through all of the MFC, ATL, source and include folders, all of the SDK source and include folders. And then, just for good measure, it repeats the first scan (leading to the actual file), ending with a QueryNetworkOpenInformationFile call on the source file. So, by the end of all this, there are hundreds a
Chris, No, I haven't run into that problem, just a different one. I generally create all my projects the same way and have no problems, but my latest project ran into a VS8 problem. I was just starting debugging this code so I inserted an int 3 at the entry to the program so I could step through some of the initial sequences (this is a MASM console mode project). I started the program and VS was called to handle the int 3, but then VS displayed the data definition include data (INCLUDED right before the Main PROC) instead of the program code segment data. I opened the debugging window and VS displayed the int 3 code intermixed with the data definition lines. The first thind the program did was to CALL a procedure named GetMemory, so I stepped into that and VS correctly loaded the code window (but was still in the debugging window), so I displayed the code window and it was correct. I stepped out of the procedure and was back in the debugger window. I started pealing this stinking onion to the core and came up with an absolute minimum code set that kept the directory structure that I wanted to use, but would run or fail based on the addition of a null procedure at the end of my runtime INCLUDE file. It would fail if the procedure was a null procedure or if it were a real procedure, but would run if the procedure was not there at all. This minimal code set is only 51 lines long total. I have many programs structured like this, and they all work with many procedures in the INCLUDED runtime file, only this one program shows this anomoly. Dave.
-
New PC to set today. I installed VS2008 (because that's what we use here), SP1, a security update or two. But, whenever I try to debug a C++ app the IDE pauses a second or two every time I step to the next line. I've tried closing the Auto, Local, Threads windows. I've tried all the obvious options in Tools / Options / Debugging. I've told the AV crap to ignore devenv.exe. No difference. And, this happens even in the simplest native C++ app. It's not related to project size. So, I opened up ProcMon, aimed it at devenv.exe and stepped to the next a line of code in the debugger... and here's where it gets weird. After a bunch of Registry calls into the MS/Cryptography stuff (?), the IDE starts looking at the source file I'm debugging. Let's call it "c:\dev\foo\bar\mysrc.c". ProcMon shows a CreateFile call on "C:\", a QueryDirectory on "C:\dev" then a CloseFile on "C:\". Then a CreateFile call on "C:\dev", a QueryDirectory on "C:\dev\foo\" then a CloseFile on "C:\dev". Then a CreateFile call on "C:\dev\foo", a QueryDirectory on "C:\dev\foo\bar" then a CloseFile on "C:\dev\foo". Then a CreateFile call on "C:\dev\foo\bar", a QueryDirectory on "C:\dev\foo\bar\mysrc.c" then a CloseFile on "C:\dev\foo\bar". Then a QueryBasicInformationFile call on "C:\dev\foo\bar\mysrc.c". OK, it's looking at the source file and testing all the subdirs on the way down. Inefficient, but OK. BUT THEN (!!!)... it does this: CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\dev\foo\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\foo\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\bar\mysrc.c" CreateFile on "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\mysrc.c" all these end up with "path not found", obviously. AND THEN (!!!) it does the same thing in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\" - and all of the sub paths, again. And then in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\src\atl\". And then in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include\". And then... etc... Through all of the MFC, ATL, source and include folders, all of the SDK source and include folders. And then, just for good measure, it repeats the first scan (leading to the actual file), ending with a QueryNetworkOpenInformationFile call on the source file. So, by the end of all this, there are hundreds a
Chris Losinger wrote:
there are hundreds and hundreds of these CreateFile calls made, every time I step over a line (or run to a break point) in the debugger.
It needs to locate the source and program debugging symbols; and though there are multiple locations where the IDE looks for the pdb files, it would not reload these at each debugging-step. Which virus-scanner are you running?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Chris Losinger wrote:
there are hundreds and hundreds of these CreateFile calls made, every time I step over a line (or run to a break point) in the debugger.
It needs to locate the source and program debugging symbols; and though there are multiple locations where the IDE looks for the pdb files, it would not reload these at each debugging-step. Which virus-scanner are you running?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Symantec Endpoint 12 (no choice, can't disable it - it's a work PC)