Debugging Spawns A Non Terminable Process, and CLI not launching - windows

I've been fighting this little problem for a while now, so I'm really hoping I can get some help. I've been looking for a solution to this, and I found this SO question: Debugging doesn't start.
My issue is somewhat similar to the issue discussed here, except that my issue is a two-parter.
Part 1: Similar to the issue discussed on the other question. (Debug Window Doesn't show up)
When I attempt to launch my Windows 32 console application project (The simple kind that opens in the windows CLI). The CLI (or CMD) window doesn't open, and windows idles giving me a spinning cursor wheel. Visual Studio IDE (I'm using VS 2013 Community) becomes unresponsive and I cannot access any menus, or use any hotkey to "Stop Debugging". One difference from the provided SO question though, is that when I try to launch "MyProject.exe" from my project's "Debug" folder I get the same result as attempting to debug in the IDE.
Part 2: Unkillable Process
When I try to close my debug application in the windows task manager, it is not listed as an ongoing process. However, whenever I try to manipulate, delete, or otherwise modify my Project.exe application (in my Project's "Debug" folder), windows informs me that the application is in use. Confused by this, I downloaded two applications. The first was Process explorer, which showed me that I did in fact have 2 instances of "MyProject.exe" running. The second was Process Hacker, which also showed me 2 instances of "MyProject.exe". However, neither of these programs were able to terminate either of the "MyProject.exe" processes.
I am capable of terminating the processes for visual studio and restarting the IDE, however, because the "MyProject.exe" processes are still running. Building always fails with the error
"Error 1 error LNK1168: cannot open C:\Users\Brandon\Desktop\MyProject\Debug\MyProject.exe for writing"
Whenever I restart my computer, the lock files (as expected) are removed, and the "MyProject.exe" processes disappear. I can restart VS and everything works, but if I try to Debug (pressing "Start Debugging" or F5) the same issue occurs.
A process of my program is started ("MyProject.exe"), but the CLI window where my program's text should appear doesn't show up. Visual studio locks up, and "MyProject.exe" persists until the next restart because "MyProcess.exe" cannot be terminated.
My solution configuration is set to "Debug", Solution Platforms = Win32.
I have tried creating a new blank console project in VS 2013 and I get the same result: code builds fine, but I have the same debugging issue. I get an identical result with a quickly assembled "Hello World" project.
Sorry for being a noob, but honestly. I really don't know what's going on, so any help is greatly appreciated.
(Note: Running Windows 10 with VS2013)
EDIT (UPDATE):
So, I'm having the same problem with several programs in Windows 10 (most notably Allegorithmic's Substance Painter). So it looks like this may actually be an OS problem. Several of my programs whenever I try to launch them do the same thing...the program acts like it's going to launch, but then no usable window appears. Looking at my processes I can see that the process has been started, but it is once again unkillable. For reference, I am using Windows 10 Version 1511 (OS Build 10586.17).

I believe your problem might be Avast, if you are running it. I had exactly the same issues until I uninstalled it. Had upgraded to Win10 and VS2013 just froze, same as you described.
Cheers.

Related

Visual Studio Debugger Freezing for specific solution

I'm running in to an issue where my solution freezes when debugging. If I place a breakpoint at the beginning of the solution, it wont freeze and will allow me to either continue or step through just fine. With this solution however, I need it to start from a specific point in the code. When I try to start it from that specific point, it'll freeze, and the output and locals box will have a popup in each saying "Busy..". It did not have this issue a few days ago, but just started yesterday.
It only occurs to this specific solution (I can debug other solutions just fine). Using C#/.NET mostly.
Remedies I've tried: Clean/Rebuild, repair on installer, uninstall just app, uninstall app and associated files, running Release, code cleanup, upgrading/downgrading vos, placing breakpoint at beginning then jumping to next breakpoint at specified point, removing antivirus software temporarily
Running latest version of Visual Studios 19 Community at the moment.
I didn't find the solution necessarily, but deemed it to be an issue with the "Locals" box that displays all your local variables and values. If I close out of this, I can continue with debugging. From further research, it seems that tool has been known to be pretty buggy.

PyInstaller Created App WIll Launch from cmd but not from explorer

I am having some problems with a app we are making with wxWidget/wxPython and PyInstaller.
We have compiled the app into a single exe for windows but:
1) On some machines it will not launch at all. It doesn't generate a error or anything in the app logs. It just stops almost immediately.
2) On some machines it will launch fine from cmd but not from explorer. again, same behavior. It just stops almost immediately. I don't even see it pop up in the process explorer.
3) On some machines it works just fine.
Are there any tips on how I can figure out what is going wrong? Is there a way to launch a exe with a debugger?
There are a few things you may want to look into:
Did you compile it as "one file"? I have heard that one exe may be blocked by some antivirus programs. It uses a few of hacks to get everything in one executable which may be considered malicious.
Did you compile it as Windows app (no console)? You may want to enable console and run it on machine where it does not run at all from console. That way you may see why it crashes.

Visual Studio unable to load necessary dll's to run project

I am trying to run a project in Visual Studio 2010, and for some reason it seems like I can't... the command-line window is closed instantly and the debug info is the following:
'exercise01.exe': Loaded 'E:\e\work spaces\C++ projects\exercise01\Debug\exercise01.exe', Symbols loaded.
'exercise01.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\msvcr100d.dll', Symbols loaded.
The program '[5900] exercise01.exe: Native' has exited with code 0 (0x0).
what might be the cause for these two dll's to not get loaded? and is the fact program exited with code 0 related to my program not running, or is there another problem?
I know others have published such questions before, but unfortunately I couldn't fine any useful info anywhere, so forgive me if I'm re-uploading a question... I'm pretty much a noob when it comes to programming in C, and in Visual Studio in general, so please have patience (:
thank you :)
First thing to check: Are these files actually there. Maybe windows is installed in a different directory and an environment variable is pointing to the wrong place.
If the files are there it is probably an authentication problem. You are running from the command line window. You may be running this in the context of NETWORK SERVICE. Try starting the command window, by right clicking on the menu and selecting "run as administrator".
Basically, your program was started and quickly ran to completion.
When you start debugging a console mode VS project, if your program doesn't stop somewhere or hit a breakpoint, it'll just run the program and when the program exits the window will close.
This is different behavior than if you run the program without the debugger - VS will keep the console window open when the program terminates.
Anyway, you can wither set a breakpoint on main() (or some other convenient location) or instead of simply starting the program with the debugger, you can "single step" into it, which will immediately break into the debugger and stop executuion.

Destroy process-less console windows left by Visual Studio debug sessions

A known bug with a Windows XP security update KB978037 can occur with Visual Studio 2005 (and 2008) where sometimes if you restart a debugging session on a console app then the console window doesn't get closed even though the owner process no longer exists. The problem is discussed further here:
Visual studio debug console sometimes stays open and is impossible to close
These zombie windows then can not be closed via the Taskbar or via the TaskManager, and typically require a power off/on to get rid of them. Over the period of even a single day you can accumulate quite a few of them, which clog up your TaskBar and are generally annoying.
I thought I would knock up a simple C++ Win32 utility to attempt to call DestroyWindow() on these windows by passing the windows handle as a cmd-line argument and converting it to a HWND.
I'm converting the handle from a string by parsing it as a DWORD then casting the DWORD to a HWND. This appears to be working as if I call GetWindowInfo() on the handle it succeeds. However calling DestroyWindow() on the handle fails with error 5 (access denied), presumably because the caller process (i.e. my app) doesn't own the window in question.
Any ideas as to how I might get rid of the zombie windows, either via the above approach or any other alternative short of rebooting? I'm in a corporate environment so installing/uninstalling updates/service-packs etc isn't an option.
Microsoft's hot fix for Windows XP and Windows 2003
I know this is not what you want to hear but the only way to get rid of these windows is by rebooting the computer
Apparently the windows team is trying to fix it:
http://blogs.msdn.com/debugger/archive/2010/03/11/help-my-console-windows-won-t-go-away.aspx
but not much seems to be happening
This issue is still a problem with Visual Studio 2010 on Windows 7!
See this thread

Stop VB application from running in background

I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?

Resources