I have noticed a weird issue when running a console program (that I have written) from the console itself, instead of using VS's Start option.
When I run the program, there will be multiple (2-3) processes that are (supposedly) running my program (they have the same name), although I can only see one instance running on the desktop.
When I close this instance, one of these processes also ends but the others don't and I can't close them, no matter what I try (task manager, taskkil). The only way I can close them is restarting the computer.
The programs I write don't do anything special, and it's the same situation even with the most trivial "hello, world!" program.
Note that this only happens when I run something I have written and I run it from outside VS.
In any other case the issue is not present (as far as I can tell). I'm using Visual Studio 2013 Ultimate 32 bit on Windows 7 Ultimate SP1 32 bit.
Related
In my Windows Forms app I use Console.WriteLine to spew debugging information to Visual Studio's Output window. I prefer this to Debug.WriteLine because it works even for Release builds, and for speed reasons I need to do my debugging in Release mode. But I wonder: if I leave those Console.WriteLines in my app and deploy it, will they affect the speed of the deployed version? I know that Visual Studio somehow "attaches" to the app's console output to show the results of Console.WriteLine. My question is, when nothing is attached in that fashion, is Console.WriteLine a no-op (or at least a very fast operation)?
After reading the forum thread linked by #bwegs, I decided to do a quick test. A million calls to Console.WriteLine with the debugger attached took a long time (actually I stopped the app rather than let it run to completion). Running the same exe from File Explorer (not attached to the debugger), the same million calls returned essentially immediately. So, for my purposes, Console.WriteLine is fast enough without a console attached to leave in my application.
I have a c# winform application, when I run it from Code, from Visula studio, It works well. But when I built exe for the same and running the same Hangs after working well for some time even it shows 0% CPU utilization in Hang state.
Hoping for a little help for solving the same problem would be very much useful from PRO people here.
Even a pro would have a pretty hard time diagnosing the problem without even a single line of code posted.
But that's okay: we can help you help yourself. :)
Run the program without Visual Studio, wait for it to hang. Then start up Visual Studio and use the "Debug/Attach to process..." command to attach the debugger to the hung process, pause execution, and take a look at what it's doing (or not doing).
Ok, this is a somewhat odd question, but I found a problem similar to these:
Debugged Program Window Won't Close
Unable to kill instances of cmd.exe on Win XP
How to close an "orphaned" console window that was opened from within visual studio?
I've found this problem recently on a production environment, oddly enough this machine did not have VS installed, and I was not debugging, but the behavior was exactly the same. The only thing I've found that really worked was using PSKill (http://technet.microsoft.com/en-us/sysinternals/bb896683) to close csrss.exe (which controls all console windows). This, obviously created a crash, but I was able to reboot the machine. I found this particularly helpful, provided such machine was not physically accessible.
The box details are:
Pentium 4, 1GB RAM, Windows XP SP2 (mind you, this is not my ideal setup, but not for me to decide :P)
I would, however, like to know if there is a way to prevent this from happening again.
I want to emphasize, there is NO VS installed on this particular machine, and the program running is not a Debug build, but a Release one. I did try Microsoft's KB 982551 hotfix but to no avail.
The particulars for the app are like this: It opens and connects to another process via named pipes, and then it will close if communication is interrupted or you close the console window via the X button or typing 'q'. Apparently the named pipe went down somewhere along the way, and the app stayed alive (which does not happen in any other cases, just this one).
Can you think of a way of tracing/reproducing this behavior in a more easily controlled environment?
I'll be happy to post any part of the code if you ask for it, I'm not doing it right now because there are like 5 different files that do the full job.
Edit: Oh, I forgot to tell you, the target machine does not have KB 978037, just in case you were wondering.
First of all, when I start the application normally (double-clicking on the exe), it works perfectly: the notify icon is always appearing in the system tray. It also works well when the application is launched at the end of an msi Setup (Run exe after msi installation?).
However, when the application is launched from an msi running in quiet mode, my notify icon isn’t always appearing, but the application is functional: I can access the contextual menu with a keyboard shortcut. I tested on three computers running under Windows XP and the success rate is around 50%. I also tested on Windows7: it works perfectly.
I know that there are some issues with the notify icons during the startup in Windows XP, but I don’t know if it is related (http://www.google.ca/search?hl=fr&q=notify+icon+not+appearing+Windows+XP&aq=f&aqi=&aql=&oq=&gs_rfai=
So, I was wondering if any of you guys ever experienced this problem. Do you think it’s a Windows XP bug? Or is it related to who is launching the application (msiexec vs .exe)? I don’t think it could be an error in my code, since it’s working well when I start it directly.
You must realize that when you run silent ( /quiet /qn UILevel=3 ) that the InstallUISequence doesn't run, only the InstallExecuteSequence does. Therefore you need to schedule your custom action to run at the end of the InstallExecuteSequence when running silently so that your C# program will run and place itself in the tray.
For those that question this requirement, it's fairly normal to do this. As an SMS Admin I would push out packages silently that would shut down a tray app, uninstall the old version, install the new version and put the try app back. All this without the agent barely notice it was ever missing.
Is it possible to rise a cmd.exe processes from the silent background mode to the visible foreground so I can LOOK at them?
Problem Background:
I'm using VS2008 working with a very large solution containing C#, C++, and Fortran. Occasionally (a few times a day) when building my project the build hangs and does not allow me to do anything in VS (resulting in the need to kill the process). I have checked the output box, and there appears to be nothing helpful there.
Possible Cause:
I am thinking that maybe one of the cmd.exe windows that are spawned in the background may be waiting for some form of input, but to investigate I need to see those windows.
Search for Other Causes/Solutions:
If not this, is there a way to try to check and see if there is something else going on? Is this a problem anyone else is having. (Note: killing VS and reloading often fixes the problem first try, and the build process takes less than 15 seconds.)
If stopping and restart fixes the problem, I guess it's not an input problem.
For example when my build project halts, it's always the VB6 project or SVN that are upset. (strangely the VS projects always work fine).
Once one of these halt, they halt until they are fixed. Thus for the VB projects run and work-out what the model dialogue is saying and fix it. or on SVN it usually need a clean-up run on the directory.
The intermittent nature suggests some sort of timing issue, like a file been lock open etc.
You could attach another copy of visual studio to the cmd.exe and see where it's at. Not sure if you can get symbols for it, so it might be fun to diagnose.