Recently my Visual Studio started to experience a delay before the program Starts Without Debugging.
This happens only when the following are met:
Console application
Start Without Debugging
There has been any change in the editor window from the last time program run.
After pressing Ctrl+F5 console application window opens and the cursor is active, but the execution is delayed.
The delay seems to be consistent in length (7-10 seconds), and not depend on the size of the code. I have checked two different installations of VS (2013 and 2015) on the same computer and the problem persists.
I have also checked that this delay occurs even for an empty Main().
There is a possibility that I have enabled some kind of an option/function in VS that causes this very specific delay, but I am not sure when this issue started occurring so I cannot trace back the change.
What could be the reason for this delay?
I will be grateful for help in this matter.
I made many attempts to diagnose the issue of the delay and one of the times that I pressed ctrl + F5 I have spotted a window opening in the background.
(It was definitely not visible everytime i tried to run without debugging).
It turns out that a functionality of Avira anti-virus had been scanning the code before it run for the first time. That is why when I made no changes to the code there was no delay.
Avira "Protection Cloud" is the name of the functionality responsible for the delays.
Link to Avira page about it and how to disable it: https://www.avira.com/en/support-for-home-knowledgebase-detail/kbid/1514
Sometimes if I have multiple editting windows open, this slows starting and stopping the debugger. Close all but those you are interested in and try again.
Related
I want to capture a stacktrace of an application which sometimes stops responding for few minutes.
When the application stops responding, the windows desktop also stops responding to mouse clicks, although some other already running applications are working fine at that time (for example windbg works fine, ProcessExplorer refreshes its screen, but does not respond to mouse events).
While the application is non responsive, it is actually taking about 80% of one CPU core. That is why I would like to get a stacktrace.
The misbehaving application usually takes about 2-3 minutes to do its strange job or if Ctrl+Esc is pressed it becomes responsive immediately (and the start menu opens of course...)
I have WinDbg attached to the misbehaving application and when I issue the Break command, the break-in does not happen until the application starts to respond again.
From what I understand the break-in actually creates a remote thread which pretty soon calls DbgBreakPoint.
What could be preventing debugger's thread from executing?
EDIT:
First of all thanks for your help!
I was also thinking that this might be caused by a bad device driver or something that installs a system wide hook somewhere.
I was thinking to enable kernel debugging and get a stack trace from the kernel for the offending thread or enable manual bluescreen trigger to produce a dump and look at that afterwards.
Process Explorer and Process Monitor does not reveal anything interesting. They also become unusable when the bug is triggered (updating their windows but not responsive to mouse or keyboard).
EDIT2:
Background info:
App uses QT, OpenGL and also DirectSound and runs on Windows 7 SP1 x64
I am currently suspecting something with the graphics part.
The strange thing is that if a system-wide lock is taken (like GDI Lock), this would prevent drawing of other Windows, but that does not happen. WinDbg on same machine works fine. ProcessExplorer updates but does not receive mouse clicks, Desktop updates but no mouse clicks.
I currently have a kernel debugger attached...
EDIT3
ETW was most useful for debugging. It turns out that Qt's main event processing loop goes crazy. PeekMessage and MsgWaitForMultipleObjectsEx (with 0 timeout) gets called in a tight loop. That is where the high CPU usage comes from.
It looks like the App is generating/getting loads of messages at that time. But it is not easy to see what the messages are (or I don't know how to access function parameters in ETW). Using a debugger also does not help much but, with a breakpoint in the QT's event loop leads me to believe that WM_TIMER messages are the culprit.
Given that the desktop also misbehaves during this time, it sounds like your app isn't necessarily misbehaving but merely aggravating a bug elsewhere (e.g., in a device driver or some crummy anti-malware code that has injected itself into other processes). Stack traces from your app may or may not be very revealing.
If the problem is easily reproducible, I'd set a breakpoint somewhere in the "middle" of the app and see if the problem happens before or after that. Then move the breakpoint until you find the last instruction your app executes before things go bonkers. Figuring out what your app does that triggers this behavior may give a clue as what's going on.
Another option is to try using some system-wide debugging tools. First, I'd peak in the Event Viewer to see if there are suspicious error or warning events posting in proximity to the moment the machine goes haywire. Then I'd try a tool like Sysinternal's Process Monitor or Process Explorer to get a better view of what's happening. You might also try ETW to capture a system-wide trace of what's happening on the system that you can study after the fact. (ETW can be hard to use, so check out Bruce Dawson's UIforETW.)
Use ETW to find the cause. Install the Windows Performance Toolkit (part of the Win10 v1511 SDK: https://go.microsoft.com/fwlink/p/?LinkID=698771 which is the last version that works in Win7), run WPRUI.exe, select CPU Usage and click on Start.
After you captured the hang, click on Save. Wait until WPRUI is finished, open the ETL in WPA, setup and load debug symbols in WPA.
Drag & Drop the CPU Usage (Precise) graph to analyse pane and look for WAIT (µs) max for your process to see that long hang and expand the stack to see where it happens.
I'm using xamarin studio and monotouch for developing iphone applications. When I set break points on my code and start debugging with the xamarin studio, the debugger breaks the codes on the break point correctly, but the problem is that when I trace the codes with debugger after some seconds ( maybe 30-40 sec) the debugger stops debugging, just like a crash. What should I do?
EDIT
I noticed that it is not because of the break point. Whenever I do not work with the phone after a few seconds the debugger disconnect and stop debugging. Is this really a bug? I think maybe there is a setting that if I change it then the issue will be fix.
Isn't this done by the iOS operating system??? doesn't it only give you ~30 seconds to return from the first event otherwise it kills the application process ? So if you sit in the debugger then it will kill that too?
If it's a bug, verify if there is a newer release and update you copy.
Otherwise, report it to the software providers for a solution.
I was profiling an application I am developing, and I saw unusual explorer.exe processor usage, almost 15%!
This is very high for explorer, I launched process explorer and then I saw this:
I click "kill" and explorer works fine..
this happens every time explorer restarts / startsup.. How can I detect which application or what is causing that thread to launch and how do I prevent it from launching? My explorer works fine without it.
I suspect this is a virus but none of my AV software detects it..
Can anyone help me out?
You have a 3rd party components which creates dynamically code (green) and this code creates snapshots of programs (red) with this function: kernel32.dll!CreateToolhelp32Snapshot
Use AutoRuns and ShellExView to disable all 3rd party tools until you find the code which causes your CPU usage.
Visual Studio 2005 C++
Windows XP Pro
I have a sample application that I am testing, that links with boost libraries.
However, the program runs ok. However, when I try and stop the program by clicking the 'Stop Debugging' button. The program ends, but the console window remains open. So I have many of them, as during my testing I am starting and stopping the application.
Even when I try and close it by clicking the close button it has no affect. And it doesn't seem to appear under task manager when the program ends.
The only way I can close them if I reboot windows.
I am thinking it might be a thread that has not closed, and maybe that is keeping the console windows open.
Many thanks for any advice,
I have also seen this issue, I think it happens when a mutex or semaphore is still locked, or a thread hasn't cleanly exited. The only way I've found to prevent this is to make sure all mutexes/ semaphores/threads are cleaned up after before stopping the debugger.
Also it's interesting to note that this problem doesn't happen on Windows 7 or Linux. I have tried stopping the same program at the same places and the program always cleanly exits.
Good luck and happy coding!
I have a small Win32 console application and when executing from the debugger the console takes about five seconds to appear. If I place a breakpoint on the last line of main, the break point is hit immediately, so the application is already finished but the console does not appear for about five seconds. I have removed all my breakpoints using 'Remove All Breakpoints', restarted Visual Studio. No dice. The console appears very quickly launching outside of the debugger, using CTRL-F5. Any ideas?
Thanks
Debugging an application causes all sorts of notifications to be sent to the debugger - all DLL loads, thread creates, etc. The debugger may be loading symbols during this time as well. All of this will slow down the launch of the process and it'll take longer to get to the point where it creates the console.