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.
Related
I'm sure this has been asked and answered, and I apologize for that, but I'm not really even sure what I'm looking for or need to do. I'm an electrical engineer that can play with programming, but when it comes to servers and remote stuff, I get really lost.
Anyway, here's the stick. I'll try to be specific.
I'm not sure this part matters, but I'll try to explain for clarity's sake. We are developing a machine. This machine is run by an IPC. The IPC is basically a PLC that has embedded Windows 7, and the IPC itself is programmed with Structured Text which is written in VS2013 (doesn't work on newer versions). In order to 'activate' the programming and parameters that we set in VS2013, this computer must be connected to the machine with an ethernet cable. I can also remote in to manually control the machine from this computer.
For an operator to control the machine in general, a CS major wrote a program that we call the HMI, or Human Machine Interface. I access and update the code for this, which is written in C#, through VS2017. The project is set up as a solution, and in order to 'activate' this programming after making changes, I just build the solution and copy the dll file over to the machine, through the remote interface. On that machine, we just click an executable that starts the IPC and then I'm guessing the IPC has been linked to the HMI program, because that opens shortly after that.
Ok, now, I'm trying to implement a new feature into this HMI and I'm running into some unknown error. In order to correct this with any program I've written in the past, I would normally set a breakpoint and/or run the debugger and go through step by step until it breaks. However, since this program has to run in tandem with the IPC, which it passes values to and receives output from, it's more complicated than that.
The CS person I mentioned no longer works here, but his note says that the debugger can be run as long as I'm connected with the ethernet cord I mentioned. When I try, though, I get "A project with an Output type of Class Library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project."
Now, from googling, I've found and tried to set the solution as a startup project, but it didn't seem like anything happened when I selected that, and furthermore, the error persists. I'm guessing that I need to do the latter, which is to 'add an executable project to the solution and set that as the startup project'... but I really don't know what that means, at all.
Do I 'add an existing project' (under File)? If so, would that be the project/solution from VS2013?
Or do I somehow need to add the executable that we click on the machine?
I sound like an idiot, I know, and that's because I am when it comes to this stuff, haha. It may be too complex for anyone to even attempt to answer, or so simple that I'm way overthinking it. I have no idea at this point, and I'm desperate.
That said, I would really appreciate if someone had any idea. Regardless, thank you for your time.
You can debug an executing process by using Visual Studio's Attach to process tool which is in debug menu. This will attach your source code to an executing process as long as the code and process code match.
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.
I'm now working on some pretty big application with really nasty code. The problem is that from time to time the whole GUI of the app is freezing and stops responding (and after some time Windows wants to take the app down). I have a really big problem to even look where to debug the app, mostly because when this thing happens and I pause it in the VS debugger, it highlight the line:
CardWindow.ShowDialog();
It's not helpfull at all. Also when this thing happens it tends to grow the app size in the memory, ocasionally throwing OutOfMemoryException.
I also checked whether it might be some kind of an infinite loop in one of created threads, but VS shows me that only the main thread is active, and the rest are either ended or not running at all (the thread implememtation is also really poorly written).
The application uses remote objects within local networks, and some threads are used to transfer photos and other data from clients to server, but I don't know how to check if this is what it's causing it. But when the server app hangs, the clients are still fully capable to connect with it.
Short info of how it's made: the app uses Firebird engine to store its data. The DB is on the server machine, and the clients are connected via local LAN to it using standard Firebird C# library, and the app instances communicates with each other using remote object (the server is also a client).
It's the second week of debugging and I'm getting pretty desperate as I'm getting out of ideas of even how to check what's wrong. The fact that the bug appears randomly also doesn't help.
Can anyone give me some ideas of how to find a trace of this bug?
Using C# .NET 4.5 and WPF with Visual Studio Ultimate 2013 and Firebird 2.5
I'd suggest using a profiling tool to assist in finding the problem
What Are Some Good .NET Profilers?
In addition to #DerekTomes. The System.Windows.ShowDialog method, Described in: Window.ShowDialog Method, all other windows are disabled and return only when the window is closed. Check to make sure the window is eventually closed(this.Close() in the CardWindow.xaml.cs or whatever .cs file) or use CardWindow.Show() instead of CardWindow.ShowDialog() so other windows remain running while the CardWindow is running.
I finally figured it out.
When the function that usually hanged the app after 30th run launched, I could see that some of it ran (the window's title changed as it was supposed to). I've found this function and after every single line put:
this.Title = "1";
SomeFunction();
this.Title = "2";
AnotherFunction();
this.Title = "3";
// and so on
I localized what was causing the problem; there was a function that changed the GUI significantly (lots of foo.Visibility and foo.Opacity) and ran in some weird loop. It was fine for the first 20 times to run it, but after 30th it slowed down the app, and after 40th - caused crash.
It now runs only once when it needs to and the problem does not appear. I suppose it caused GUI memory overflow of some kind.
Anyway, thank you for your answers - I ran memory profiling, but it slowed my app down to that point it was impossible to use it.
A few applications on my PC have been doing a detection wether a restart was done by Windows Update or not. This is observable due to them restarting after the automatic Windows Update reboot.
This is very helpful since those applications reload changes, even unsaved changes or restore tabs (in case of a browser). Examples of applications that do this:
Google Chrome
Microsoft Visual Studio
Microsoft Paint
In all cases the applications save the state they were in before the reboot.
(My PC actually woke up from a standby state automatically, and rebooted itself while instaling updates. Too bad it didnt go back to standby after doing this.)
My question is: How do I programmatically detect this kind of reboot? It seems to be reliably detectable before the reboot.
The question How can I get the Windows last reboot reason might seem like a duplicate, but no answer said anything about updates.
I code in C#, so an answer in C# would be helpful, though I can read C and C++ too, for example.
See Application Restart:
An application can use Application Recovery and Restart (ARR) to save data and state information before the application exits due to an unhandled exception or when the application stops responding
and:
or if the computer needs to restart as the result of an update.
The applications aren't detecting the restart reason after the fact - they've been architected to use this API. There isn't (so far as I'm aware) a managed API for this.
A couple of clicks away is Saving data and application state when application is being closed due to a software update. Again, no managed API.
Normally when Windows Reboots, it performs a restart by using shutdown.exe and the /g flag which saves the state of all registered running programs before restart. What you want to do is to Register your application for restart. There is a good sample with documentation for this by MSDN. It is available in C# and C++.
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.