starting app to debug in takes "forever"

starting app to debug in takes "forever"

Post by » Wed, 30 Aug 2006 06:41:08


since two days I've the problem that I can't start any applications
anymore to debug them.
The output window says:

'jedid.exe': Loaded '...\...\appname.exe', Symbols loaded.
'jedid.exe': Loaded 'C:\WINNT\system32\NTDLL.DLL', Symbols loaded.

(then 20min nothing, no cpu-load, no-disk i/o, perfect silince)

'jedid.exe': Loaded 'C:\WINNT\system32\msvcrt.dll', Symbols loaded.

(then 5min nothing, silence again)

'jedid.exe': Loaded 'C:\WINNT\system32\KERNEL32.DLL', Cannot find or
open a required DBG file.

(then 5min nothing)

'jedid.exe': Loaded 'C:\WINNT\system32\ADVAPI32.DLL', Symbols loaded.

...and so on. Right now I'm at about 25+ dlls, I can see the
Application in the taskbar, the window is there, but not responsive. I
cant pause the debug. The only thing I can do is kill VS2003. Killing
the app will not work.

The only thing I changed (well, the company): they installed all recent
security updates, and there is no way to uninstall them.
This affects all programs I wrote. Even a simple "Hello World" (which I
didn't wrote ;)

My config:
Win2k with all SP's and updates/fixes. 2003 (tried it w/ and w/o SP1)

Any idea what got screwed up?

starting app to debug in takes "forever"

Post by Oleg Staro » Wed, 30 Aug 2006 15:30:15

What happens if you go to <VSInstallDir>\Common7\IDE directory
and rename symsrv.dll (so that the de *** could not find it)?
Will the problems continue after that?

[VC++ MVP ]


starting app to debug in takes "forever"

Post by » Thu, 31 Aug 2006 00:05:24

Hi Oleg,

I searched for all symsrv.dll (found 4 in different versions) and
"disabled them", VS still runs fine. Rebuild the app. Started it, works
fine. Renamed the dll back, still works.

Don't know if this was the cause for the problem... but hey, who knows
or cares. Its fixed.


starting app to debug in takes "forever"

Post by Zmxhdml » Fri, 01 Sep 2006 21:22:02

"Oleg Starodumov" ha scritto:

tanks you very much,
your suggestion works fine for me too (i was thinking to hang me up
could you complete the information telling us what is symsrv.dll and why it
was there (ie what i must not do)?

starting app to debug in takes "forever"

Post by Oleg Staro » Fri, 01 Sep 2006 22:38:36

VS de *** (since VS2002) supports symbol server access.
It means that it can, while loading symbols for a module, download them from some
preconfigured locations on the network (symbol servers), if symbols could not be found
on the local machine.

The most important use of symbol server is to download symbols for various
operating system DLLs (their symbols are available on the symbol server maintained
by Microsoft, at

More information about symbol server and VS can be found here: ;en-us;823242
and detailed information in the documentation of Debugging Tools for Windows.

Symsrv.dll is the component that is responsible for downloading symbols from
symbol servers. If it is renamed, symbol server feature is disabled.

While very useful, symbol server access usually slows down the startup of
debugging sessions, because of the following reasons:

- Contacting symbol server takes time, and downloading symbols takes even more time.
The latter is taken care of by using local symbols cache, but the former still exists.

- Some modules do not have symbols at all (e.g. 3rd party modules), and thus
it is waste of time to contact symbol server and try to download symbols for those
modules. It can be solved using exclusion list, as shown here:

- Incorrectly set symbol server path can cause the de *** to spend unnecessary time
trying to contact a non-existing symbol server (symbol path should be checked
in _NT_SYMBOL_PATH environment variable and also in VS settings)

- Generic network problems (not related to symsrv.dll itself) can make symbol
server access very slow. In this case renaming symsrv.dll provides a temporarily
solution, until the network returns to normal.