Debugger takes a lot of time to start

[abhimodak]

Hi

I am experiencing a lot of start up time taken by the debugger. In the left bottom corner of the visual studio, I see the "Loading symbols for c:Windows\\system32\\*.dll" where * corresponds to a variety of dlls.

Although not to the same extent, after hitting the "stop debugging" it also takes a "realizable" amount of time.

The start-up time is the longest for the first run after a build. For subsequent runs, it goes down however is still long enough.

Does this give any clue as to what may be going on?

Abhi

[ZlamalJakub]

I observed tis behavior in my appliation, it uses about 10 dll files so it takes time to load symbols to debugger.

When you run your debug next time, dlls are probably still in memory and it speeds up loading.

Now it seems this slow debug start disappeared and everything is fast. I do not why?

Jakub

[IDZ_A_Intel]

Probably irrelevant, but there has been the odd version of a windows/office DLL (gdiplus??) that has escaped into the wild with a hardcoded internal path for its PDB that pointed to a directory on an internal microsoft file server. Every time you tried to debug an application that used this DLL the debugger would try and contact this (remote and inaccessible) server to get the relevant symbols. Debug/attach start-up times were horrendous (~30 seconds).

(You can see symbol search paths for a DLL from inside the VS 2005 IDE using the Debug > Windows > Modules" window, right clicking on the DLL of interest and selecting Symbol load information)

To fix I edited the start of the path to the PDB inside the DLL image to point to a non-existant local drive.

[Vieira__Dalmo]

I'd like to report that I started having the same issue, but for me it takes several minutes (I'd say 5 mins or more). The problem startedafter I installed the latest update (11.1.060 ia32).

It is happening everytime I try to start the program in debug mode, so the debugger is unusable now.

How do I revert to the previous version?

/edit: using a previous version of the Fortran compiler does not help the issue. Still takes about 5 minutes for the program to start in debug mode.

[abhimodak]

Hi

I think, at least in my case, this has something to do with enabling the parallel debugger extensions. If these are enabled (Debug-->Exceptions-->Win32 Exceptions; all three are selected), I can see (i.e. I get enough time to read) the dlls mentioned in my original post in the left bottom corner of the VS.

On the other hand, if these exceptions are not enabled (boxes unchecked), the loading info displayed in the left bottom corner happens too quickly to read. However, sometimes I get a pop-up message that tells me to enable the parallel debugger extensions.

While the former i.e. debugger taking a lot of time to load (and unload) happens every time, the pop-message asking to enable the extensions is not 100% reproducible i.e. sometimes I get it sometimes I don't.

Abhi

[Steven_L_Intel1]

If you want to revert to a previous version of the Visual Studio integrations, uninstall the later version, delete the "Intel Fortran" folder under the appropriate Visual Studio folder, then install the older version.

[abhimodak]

Hi Steve

I see now that you were replying to dalmoanv's post. Again I am wondering if the debugger taking a long time to load behavior and its connection with the parallel debugger extension has been seen by someone else.

Abhi

[Steven_L_Intel1]

I was replying to dalmoanv.

[Vieira__Dalmo]

I unchecked the three entries in Exceptions/Win32 Exceptions that relate to the debugger extension and the delay does not happen, with either 11.0 or 11.1 (newest) version of the compiler. If I turn those on, there's the huge delay starting and it runs much slower. Also, I started the program in the debugger and let it run (no breakpoints). It's 10 times slower when "thrown" is checked for those three boxes (30min instead of 3mins).

Does the compiler work correctly if those are not checked?

Thanks,

Dalmo

[Steven_L_Intel1]

The compiler works fine regardless. Unchecking those exceptions means that you might get "unhandled exception" errors when debugging your program.