IT story

Visual Studio의 느린 디버깅 문제

hot-time 2020. 9. 17. 18:59
반응형

Visual Studio의 느린 디버깅 문제


내 Visual Studio에서는 C # 콘솔 응용 프로그램에서 한 줄의 반환을 작성했지만 F5 키를 누른 후 실제 코드를 실행하는 데 1 분 정도 걸립니다 (키를 누른 후 단일 return 문에서 중지하는 데 걸리는 시간을 의미합니다. F5-Main 함수의 return 문에 중단 점을 설정했습니다.) 무엇이 잘못되었는지 궁금합니다. 체크리스트가 있습니까? 감사!

Visual Studio 2008 VSTS 버전을 사용하고 Windows Server 2003 x64에서 디버깅하고 있습니다.

미리 감사드립니다, 조지


당신이합니다 (Ctrl-SHFT-F9 또는 사용)은 "모든 중단 점 삭제"버튼을 클릭 할 필요가 당신은 --- 메모를 모든 중단 점을 삭제해야 할 수 없습니다 단지 하나씩 삭제합니다. Visual Studio가 솔루션 설정을 망가 뜨린 경우 후자가 작동하지 않습니다. 이것이 작동하려면 먼저 중단 점을 추가해야 할 수도 있습니다 (영리 하군요?).

최악의 경우 .suo파일 을 삭제 하고 Visual Studio가 처음부터 새 파일을 시작하도록 해야 할 수 있습니다 . 그러나 개인 솔루션 구성 설정은 손실됩니다 (다른 솔루션이 아닌이 솔루션에 대해서만). 그러나 이것이 문제인지 여부를 결정할 때까지 일시적으로 파일을 이동 / 이름을 바꿀 수 있습니다. 이렇게하면 언제든지 다시 이동할 수 있습니다. 일부 온라인 리소스에서 .ncb파일 삭제 (이동 / 이름 변경)를 권장하는 것을 보았습니다 .


나는 이것을 전에 본 적이 있습니다. 모든 중단 점을 삭제 한 다음 원하는 중단 점을 설정하십시오. F5를 누르십시오. 지금은 더 빠릅니까?

방금 .NET 소스 디버깅 기능 설정에 대해 언급 한 것을 확인했습니다. 이를 비활성화하면 Microsoft의 원본 서버에 대한 네트워크 연결이 느려질 수 있습니다. 또한 도구> 옵션> 디버깅> 기호에서 기호 서버 연결을 비활성화합니다.

또한 도구> 옵션> 디버깅> 일반에서 "속성 평가 및 기타 암시 적 함수 호출 사용"을 비활성화 해보십시오.


또는 솔루션 (.sln) 파일 옆에있는 .suo 파일을 제거하십시오. 이것은 디버그 세션을 시작하고 중지하는 데 오랜 시간이 걸리는 문제를 해결했습니다.


이 문제가 있었다. 나열된 모든 조언을 시도하고 모든 Visual Studio 확장을 제거한 후 마침내 IntelliTrace가 활성화되었음을 알게되었습니다. 비활성화하면 모든 것이 해결되었습니다.

http://msdn.microsoft.com/en-us/library/dd264948%28v=vs.100%29.aspx


많은 중단 점이 설정되어 있습니까? 이는 시작 시간을 정말로 늦출 수 있습니다. 새 모듈이 프로세스 주소 공간에로드 될 때마다 모든 모듈이 유효한지 확인해야합니다.


도구 / 옵션 / 디버거 / 심볼로 이동하여 공용 기호가 설정되어 있는지 또는 UNC 네트워크 경로가 설정되어 있는지 확인하십시오. 또한 도구 / 옵션 / 디버거 / 일반을 확인하여 소스 서버가 설정되어 있는지 확인하십시오.

이들 모두는 느린 네트워크 속도 또는 사용할 수없는 서버를 기반으로하는 디버깅에 영향을 미칠 수 있습니다. 5 분의 대기 시간은 네트워크 시간 초과입니다.

옵션에 아무것도 설정되지 않은 경우 _NT_SYMBOL_PATH 환경 변수가 설정되어 있는지 확인하십시오.


제 동료는 매우 느리게 응답하는 Visual Studio를 사용했으며, 디버깅하는 동안 단계를 수행하는 데 문자 그대로 몇 분이 걸렸습니다. 근본 원인은 VS가 실행되는 동안 미친 안티 바이러스 프로그램 (위협 화염)으로 밝혀졌습니다. 프로세스를 종료하면 즉시 모든 것이 해결되었습니다.


필자의 경우 디버그 기호 "Automatically load symbol for"옵션을 "모든 모듈"에서 "지정된 모듈 만"으로 변경하면 문제가 해결되었습니다. 도구-> 옵션-> 디버깅-> 기호에서이 옵션을 변경할 수 있습니다.


다른 원인 플러스 ... 문제를 찾는 방법

나에게 그것은 ShowOtherThreadIpMarkers 옵션 이었습니다. 값이 = 1이면 vs (2010)이 견딜 수 없을 정도로 느려집니다 (각 디버그 단계에 대해 3-5 초. 값이 0이면 다시 빠릅니다.

그 옵션은 무엇입니까? 나는 모른다. vs 사용자 인터페이스를 통해 찾을 수 없습니다. 가능한 모든 디버깅 옵션을 선택 취소했지만 아무것도 작동하지 않았습니다.

그래서 내보내기 설정 가져 오기로 이동하여 이전에 저장 한 이전 설정을 vs가 다시 빨라질 때까지 거꾸로로드 한 다음 vssettings 파일 등을 비교했습니다.

중단 점에서 중지 된 디버그 모드에있는 동안 설정을로드하면 즉시 적용된다는 점에 주목하고 싶습니다. 디버거를 중지하고 다시 시작할 필요가 없습니다.


Travis가 링크 한 ScottGu의 블로그에서 : "최근에 들었던 또 다른 성능 문제는 Google 툴바 추가 기능을 사용하는 사람들이보고 한 문제입니다. 어떤 이유로 Visual을 첨부 할 때 시간이 오래 지연 될 수 있습니다. Studio 디버거를 브라우저로 전송합니다. 웹 애플리케이션을로드하는 데 오랜 지연이 있고 Google 툴바 (또는 기타 툴바)가 설치되어있는 경우이를 제거하여 문제의 원인인지 확인하는 것이 좋습니다. "


더 이상 존재하지 않는 서버에 대한 오래된 네트워크 매핑이 없는지 확인하십시오 (네트워크 시간 초과로 인해 사용자가 죽을 수 있음). 또는 프로세스 모니터 와 같은 것을 사용 하여 네트워크 (또는 기타 파일 오류)가 오랫동안 차단되고 있는지 확인합니다.


Are you using a Symbol Server to download symbols for Windows DLL's?

If so disable that as it can take some time but I wouldn't expect that to cause long delays in a basic console app.

Tools > Options > Debugging > Symbols


I know this is an old topic but for what it's worth...

I've found that if I've had a seperate IE window open for a long time it can take up to a minute to start debugging. Close all IE windows and debugging starts immediately.


In my case Google Toolbar was slowing down my debugging. gplus_notifications_gadget.html just kept going on and on overloading the debugger. I wanted to keep the Google Toolbar because I use it on a regular basis, so I just disabled the G+ notification button (the small button besides the profile button.) It is happy now.


Running under the debugger for me was roughly 10x slower than running without debugging.

After trying every solution suggested here, I went through every debugger setting and enabled/disabled to see if it made a difference.

For me, it turned out that disabling Suppress JIT optimization on module load in the debug settings massively improved things.


I had the same issue in VS2010, with stepping in the code excruciatingly slow (between 3 to 10 seconds). However, none of the above settings modification did the trick. I eventually found the ultimate solution, which would work in all of the above post issues: reset all your settings, as described here.

You may first want to save a particular part of your settings, for instance I first saved my color theme (Solarized-like), then restored it after the global reset.


For me, the setting that killed performance (windows 8 even hanged except for mouse movement) was to UNCHECK "Break all processes when one process breaks" in Options -> Debugging -> General.

Hope this helps anyone.


Just one more cause of a slow Visual Studio debugging experience...

Long time ago I enabled FusionLog to see what was causing an assembly binding problem.

Make sure you disable it after using it. Why? Because it writes a lot of logging data to the disk while enabled.

This is the FusionLog key on Window's Registry [ regedit.exe ]:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Change ForceLog, LogImmersive and LogResourseBindings values from 1 enabled to 0 disabled.


I had this problem too, but it had nothing to do with breakpoints in my case. It was code shortcuts that I added in the tasks window:

http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--onlywhenaddingandremovelines

I'm sure there are other ways you could see a problem like this, but there is a bug somewhere that caused this problem for me...deleting all my options would have fixed this, but that is something that I did not want to do. So, I debugged it and wrote about it in my blog...your problem sounds like mine.

Thanks.


Something that has worked for me is to make sure there are no conditional break points. Other then that, I have had success fixing slow debugging by simply restarting visual studio and only opening one instance of visual studio at a time. Hope it helps somebody...


I had a similar issue and none of the other guidance seemed to help. I had rebooted to no avail. I had removed all breakpoints, deleted the suo file, checked that symbols weren't being loaded from external sources, and checked that no paths existed in the application that was unavailable.

Then, I thought to clean the solution. I noticed in the output window that C# IntelliSense reported an issue when cleaning:

There was a problem reading metadata from '{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}' ('The system cannot find the file specified.'). IntelliSense may not work properly until the solution is reloaded.

In this case, once you actually discover the error message, it tells you exactly how to resolve it. (Good job on the error text, poor job on discoverability!) I unloaded the solution's projects, then reloaded them. I was then able to successfully run clean solution. It worked, and the debugger did as well.

HTH


Closing the "Autos" window improved debugging for me in vs2008 for a big native c++ solution. Hiding it won't work, it needs to be closed.


I experienced the same slow down, and disconnecting from the network fixed the problem for me as some other comments and answers have stated (But of course that is not an ideal fix).

For my case this one simple change fixed my solution: In the project properties on the debug tab I disabled "Enable the Visual Studio hosting process." (I am running VS2010)


Get more memory and a faster HD. More details here.

참고URL : https://stackoverflow.com/questions/589338/slow-debugging-issue-in-visual-studio

반응형