visual studio .net debugging: Hi,

since two days I've the problem that I can't start any applications
anymore to debug them.
The VS2003.net 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.
VS.net 2003 (tried it w/ and w/o SP1)

Any idea what got screwed up?

[quoted text, click to view]

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

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

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.

Thanks.

"Oleg Starodumov" ha scritto:

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

[quoted text, click to view]

VS debugger (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 http://msdl.microsoft.com/download/symbols

More information about symbol server and VS can be found here:
http://support.microsoft.com/default.aspx?scid=kb;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:
http://www.debuginfo.com/tips/symsrvexlist.html

- Incorrectly set symbol server path can cause the debugger 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.

Oleg