- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using a standalone IVF 11.1.070. At some point the debugger became extremely slow. I would watch as minutes rolled by where the debugger was loading symbols from DLLs. The debugger became unusable.
I think I finally solved the problem. I went to Tools -> Options -> Debugging -> Symbols and checked the box labeled
"Search the above locations only when symbols are loaded manually"
I think this stopped the debugger from going to a Microsoft website to download symbols. The debugger is very fast now. I don't know why the debugger started doing this, because it didn't when I first installed it. I tried fixing the problem with a reinstall, but the setting must have been preserved somewhere.
Hope this saves someone else some time.
I think I finally solved the problem. I went to Tools -> Options -> Debugging -> Symbols and checked the box labeled
"Search the above locations only when symbols are loaded manually"
I think this stopped the debugger from going to a Microsoft website to download symbols. The debugger is very fast now. I don't know why the debugger started doing this, because it didn't when I first installed it. I tried fixing the problem with a reinstall, but the setting must have been preserved somewhere.
Hope this saves someone else some time.
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some time ago I experienced similar issues. The root cause of it was a Microsoft DLL installed by an update (I think it was the office variant of the Gdiplus DLL) that had erroneously stored inside it a UNC reference to its associated symbol file on an internal Microsoft server (something like //ms-server-name/path/to/where/we/built/gdiplus). Every time that DLL was loaded while a process was being debugged the debugger would stall while the operating system tried to find a server of that name on the network.
If I recall correctly, to fix it I patched that dll using a binary editor or similar, such that the stored path to the symbol file was C:\path-that-doesnt-exist\.... (keeping the altered path the same number of chars as the original path) so that no network access was required before the symbol manager decided that the symbols for that file were unavailable. Perhaps this applies in your situation too.
(I think I identified the problematic DLL using the modules window under VS (via Debug > Windows), but I might have been using WinDbg instead.)
Note that the DLL may be completely unrelated to your application/Visual Studio/Fortran (hence the problem isn't fixed by reinstalling Fortran/VS) and could easily have found its way onto your system via a operating system update or similar.
If I recall correctly, to fix it I patched that dll using a binary editor or similar, such that the stored path to the symbol file was C:\path-that-doesnt-exist\.... (keeping the altered path the same number of chars as the original path) so that no network access was required before the symbol manager decided that the symbols for that file were unavailable. Perhaps this applies in your situation too.
(I think I identified the problematic DLL using the modules window under VS (via Debug > Windows), but I might have been using WinDbg instead.)
Note that the DLL may be completely unrelated to your application/Visual Studio/Fortran (hence the problem isn't fixed by reinstalling Fortran/VS) and could easily have found its way onto your system via a operating system update or similar.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page