You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This happens because vs2017 is using the OutputDebugString API itself.
If you set a breakpoint in debugview++, it hits and vs2017 tries to send a OutputDebugString message, this whole thing deadlocks (which makes sense)
The only way to work around this, it to disable the 'capturing' in debugview++ (Log->Pause)
or not to use breakpoints.
The issue is closed as far as the visual studio team is concerned, their view is that their is no reason why visual studio should not use the OutputDebugString API. To me this is odd, because for the debugging tools (visual studio) to be outputting debug-messages via the same channel as the application under test, seems confusion to me, however, there is noting I can do about it.
I will keep this issue open here, as its still an issue to me.
we could work around this by using dbgview-agent as a back-end, because in that scenario the process catching the outputdebugstring output is not under debug
This happens because vs2017 is using the OutputDebugString API itself.
If you set a breakpoint in debugview++, it hits and vs2017 tries to send a OutputDebugString message, this whole thing deadlocks (which makes sense)
The only way to work around this, it to disable the 'capturing' in debugview++ (Log->Pause)
or not to use breakpoints.
references:
https://developercommunity.visualstudio.com/content/problem/40140/starting-up-visual-studio-is-pretty-noisy-on-the-o.html
https://developercommunity.visualstudio.com/content/problem/289651/ui-hangs-opening-menu-during-debugging-with-repro.html
The text was updated successfully, but these errors were encountered: