My Visiual studio hangs all of a sudden when debugging the windows application. It's takes while to repond and but it's closing my application. I keep getting this issue everytime in every debugging session.
Please help to fix this problem.
Your application also stops responding right? If so, I presume that your application is giving VS problems. Presumably because some operation is tying up the main thread. When that is tied up no other events can be processed (button clicks, screen redrawing, close buttons, etc). That could be caused by an infinitive loop, or perhaps Disk IO or waiting for a network connection or a database query result, or a deadlock.
My suggestion would be to do some type of logging so you can identify where the problem is at. For instance, put a breakpoint at the top and bottom of major functions. After you break at the top one, hit play. If you don't hit the bottom one you know that the problem is somewhere in that area.
Or, do some sort of logging like putting Console.WriteLn("Entering MyFunction()") at various places in the code.
Once you know where the problem is at, you can fix it.
Related
I have a script that I'm trying to debug, but the debugger immediately closes itself when it hits an error and dismisses the error message. I could manually open the log and wait for it to load every time I hit a stop, but that wastes a lot of time when it could just pop up on my screen. I figure it has to be an easy fix and I probably did something stupid, but one gets pretty tired of Google's shit when you've read blog headlines such as "THE 6 DEADLY SINS OF GOOGLE APPS SCRIPT ADD-ON DEVELOPMENT" for the 50th time in as many search queries. Anyways, rant over.
When I hit debug, the debugger will run, a white tray pops up at the bottom of my screen and stays empty. When it hits an error, it will flash the error message across the top of the window and immediately close/dismiss that error as well the tray that popped up. The tray looks like the one in the image below, except completely empty.
Has anyone else had this issue and know why it might be happening? Also, can anyone tell me if there is a Matlab-style workspace explorer that displays each user-defined variable and what kind of data it holds? I would find that extremely helpful in debugging. That, and a live in-window console/log.
This is a known issue. Star(on the top left) the issue to let Google know that you're affected and for the issue to be prioritised. Some of the features you requested is already in development
New IDE features Monaco for cutting edge code editing, streaming logs, reliable debugging and Material design. Seamless integration into the G Suite Developer Hub lets users design, develop, deploy and manage their projects all in one place.
In the meantime, You can use clasp in your local IDE.
Related question:
V8 engine no longer breaks on errors
I’ve encountered a problem I can’t solve.
I’m working on a project with MFC in Visual Studio. The problem is, sometimes GUI just stop visibly reacting, but technically it keeps doing the functions it was intended to do. It means, when I press a button, the function OnBnXXXPressed is executing, but the button doesn’t look like it was pressed, as if I’ve pressed on a picture of button, not the button itself. And it’s not just this button — every other element of GUI seems to keep working, but doesn’t show that it is working.
Also, in this state dialog windows don’t show up upon their call. If I call AfxMessageBox, the message box won’t show up, and the thread that called this function, will not be blocked; AfxMessageBox will basically be skipped.
I have absolutely no idea what can possibly cause that behavior. The question is: what should be happening in program for it to behave this way? Especially if it’s built with MFC?
The project consists of 50+ files, and every function responsible for GUI makes changes to the elements it is about. I do not know where the error is, and I ask you, to the very least, where should I look for it.
Thank you for attention!
The answer was originally provided in the comment section. My code indeed has a GDI resource leak that was provoking this behavior.
When a button is clicked, are you doing a bunch of processing, or do you return fast? If you don't return, maybe locking the UI thread. After a user presses on the button, how long is it taking before the OnClick for that finishes running?
If that's it, here's some more info: https://learn.microsoft.com/en-us/windows/desktop/Win7AppQual/preventing-hangs-in-windows-applications
The solution I've generally used for long-running logic on a UI click is to run it a background thread.
Is there a facility in Visual Studio, when debugging a desktop app, to remember where the mouse was when I hit a break point so that i may use it in Visual Studio while stepping through code, and then snap it back to that spot when I resume execution? This would help in mouseover events and other position-sensitive workflows.
If there's not something built in, would it be possible to do this with a Visual Studio plugin? Or is there a way to install a hook such that the debugger sends my application an event or interrupt that it could use to save that state on break and restore it on resume?
Thank you.
There's nothing built in to the VS debugger to do this. It's more than mouse position, there are likely subtle state changes (like focus and activation) that would be difficult to save and restore reliably.
A quick and dirty thing to do is to add some OutputDebugString messages to the code in question to give you clues as to what's going on internally without actually breaking the execution. VS will show the messages in the Output window.
The only way to come anywhere close to what you're after is to use remote debugging. You can remote debug your code running inside a virtual machine so that you don't actually need a separate physical machine.
When my program is paused in Visual Studios 2010 during debugging, like from reaching a break point and me doing a manual step through, the program window becomes impossible to view.
It is a GUI window not a console window, which I run simultaneously with my program and am still able to view. The window seems to be open it's just that when I click its icon on the taskbar it doesn't come to the front of all the other windows. When I minimize all the windows in front of it, I see the outline of the window but it is either blacked out or showing the remnants of previously expanded windows.
I've noticed this with using Visual Studio's before (various versions of it), and after trying other IDE's that didn't have this behavior I notice it more. It would be really helpful to view the program's change's as I step through the program. Anyone know how I can do this?
I searched a long while and couldn't find a single reference to this matter.
The reason the window doesn't display is that the window paint message won't be processed if the main thread has been paused. Which other IDEs let you do this? I haven't come across any native code debuggers that do this on Windows.
If you are stepping through code that is run by the main thread, then the main thread can't simultaniously poll the message pump, which is needed for the GUI to work.
If you debug a different thread, the GUI will work while you are debugging.
I use Visual Studio 2008. I haven't seen this behavior before and, as far as I know, I didn't change anything in the options.
When I press Start debugging all the possibly windows (watch 1 - 4), data sources, properties, registers (to be honest I have not even ever seen these windows before) appear in front of the code window and stay there after I stop the debugger.
Anyone has an idea what could be causing this ? (I am using CodeRush and Refactor for quite a while now)
When I close and restart visual studio all the windows are where they should be.
PS: Previously I have seen normal switching from normal to debug mode and back with some repositioning changes. That is the way it used to work. Now it is not. It has suddenly gone mad and when going to the debug mode it sometimes shows all possible IDE windows and sometimes not. When it does it no longer returns to the previous state. I cannot find this in the options anywhere.
Visual Studio remembers 2 sets of window layouts, normal mode and debugging mode. My solution is to arrange my normal windows exactly like I want them, then start debugging an application and once again arrange all of the windows the way I want, usually making it as similar to my normal layout as possible, then stopping the debugger and doing a File Exit so that VS saves my settings.
After doing that, it recalls my 2 different layouts each time.
I'm experiencing the same thing - whenever the debugger is running, switching focus back to the IDE immediately caused the debug panel to expand.
I ended up just pinning the debug panel so that it always appears when debugging, and just changing its height as needed.
To add to palehorse, another tip is Full Screen mode.