We Keep Coding

Determine if program crashed [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Detecting process crash in .NET
I'm writing a c# program that have to determine if another C++ game program (let's call it Foobar) is crashed or not.
When the FooBar program crashes it's notifying the user about the crash with a MessageBox, if you OK that windows the program closes.
So I guess I could determine if the program is crashed if that messagebox is opened/active. Problem I dont know how to do that.
Or if there is any other better solution comes to your mind, please share it with me.
Edit:
I can not edit the C++ program, and it's always a possibility that it will crash. I just need to know if it did.

Duplicate of Detecting process crash in .NET.
The heartbeat is probably the way to go, but there is another way.
When a process crashes, Windows first checks to see if a Just-In-Time debugger is configured on your system. If so, you can have that debugger attach itself to the process right before it crashes. Usually you would use this functionality to generate a memory dump as a process crashes. Whatever debugger you attach gets to know the PID and name of the crashing process. You can either utilize features of existing debugging tools, such as ADPlus, or write your own program and tell Windows that that is your Just-In-Time debugger and should be run when a process crashes. I believe you can set up a JIT debugger specifically for any process name.
See http://msdn.microsoft.com/en-us/library/5hs4b7a6(v=VS.80).aspx
I think that if you set the HKLM\Software\Microsoft\Windows NT\Current Version\AeDebug\Debugger registry entry to '"DirectoryOfYourProgram\YourProgram.exe" -p %ld' where YourProgram.exe expects a PID passed in with the -p flag, your program will be called and passed the correct PID when a process crashes.

If you have access to the code for both apps, you could setup a heartbeat message from the c++ app to the c# app, and do whatever when the heartbeats stop. For the comms you would need something like named pipes or similar. Alternatively your c++ could write to a file regularly, which your c# could detect updates to, using file monitoring.

C# Application Restart does not call program Main()

I've already wrote an application that works user base. I was looking for the best way to use for current user logging-out. So I've used Application.Restart();
Soon I found that the code doesn't work properly and Program.Main() doesn't call back again.
I wondered that my Login form Load Method is not going to perform (The Login Form is calling from program class).
So I'll really thankful if you let me know about my bugs and correct solutions.

http://msdn.microsoft.com/en-us/library/system.windows.forms.application.restart.aspx
Comment listed "Bug in VS2010 SP1"
after calling this method, the application no longer run in debug mode, it's not spawned by the IDE and all breakpoints stop functioning.
EDIT:
This is where something like log4net can really be helpful. It's a very simple library to add to your project and would let you write out debug information to a file so, even though the next instance wasn't spawned by the IDE and wont get breakpoints, you could still do some verification that it's hitting what you expect through the use of Debug traces. Just a suggestion...

A new process gets created, and it's not spawned by the IDE.
A breakpoint is not a valid way to test if Main is entered again.
See somewhat related post:
Does Application.Restart() creates new process for application or no?
If you'd like, you could write to a file or some other simple test in Main just to prove to yourself that it is entered.

Microsoft recently released a solution that allows debugging to continue after Application.Restart(), in the form of a Power Tool:
Child Process Debugging Power Tool
Blog Post
Download in VS Gallery

Visual Studio attach to process and view the code on break?

I must not have some configuration property set correctly...
Basically when I run the app as a service via srvany.exe, it starts, but a class doesn't get instantiated correctly. I've put in a 60 second delay to allow me to attach to the process, but I can't get that exe to break when it hits the break I set in the debugger (I guess that doesn't get compiled in?), and all I can view is the disassembler. Is it possible to do more?

Sounds like VS may be assuming that SrvAny is stricly native code. When you attach to it, make sure that the "Attach to" box contains "Managed code" as a selection. Also, watch the debugger attaching to the process in the output window and make sure that it says "Symbols loaded" when your assemblies are loaded (indicating that the PDB file was found successfully)

Instead of inserting delays and rushing to attach to the process in time, you can call
System.Diagnostics.Debugger.Break();
to break execution and attach the debugger programmatically.

Displaying console output?

I am currently creating a customer application for a local company. I have a datagridview linked to the customers table, and I am trying to link it up so that updates, inserts and deletions are handled correctly. I am very new to c# so I am starting with the basics (like about 2 days ago I knew nothing - I know vb.net, Java and several other languages though..).
Anywho from what I understand anything output through Debug.WriteLine should only appear when in debug mode (common sense really) but anything output through Concole.WriteLine should appear whether or not in debug mode. However I have checked the immediate and output windows and nothing is being output when in normal mode. Does anyone have any idea why this is??
Edit: I have event handlers for clicking a cell - it should output CellClicked and set the gridview to invisible when a cell is clicked. The latter works whichever mode I am in, but CellClicked is only output in debug mode. I am using Console.WriteLine("CellClicked").
Edit: Seems I may have solved it - I just set the output to Console Application in the project settings pages. It now opens a command line window as well as a windows form, but I can change the output back again when I compile for distribution. Thanks for the help.

Console.WriteLine() outputs to the console window in the case of a console app only.
You are probably looking for Trace.WriteLine().

Getting the output of Console.Write/Line() written to the Visual Studio Output window is a feature of the Visual Studio Hosting process. Project + Properties, Debug tab. This will not work if you run your app without a debugger, the hosting process isn't being used.
Using Console.WriteLine for debugging isn't the greatest solution. That code will still run in your Release build and take time formatting the output string. And prevent the JIT optimizer from doing a good job generating the most efficient machine code. Output will fall in the bit bucket, nothing to actually write it to.
And it is unnecessary, the debugger gives you much better tools to find out what is going on in your program. Take some time to familiarize yourself with its capabilities. If you want to find out if an event handler runs, just set a breakpoint. Such a breakpoint can even trace output without actually breaking. Right-click the red dot, click "When hit" and use the "Print message" option.

I think you'll like the tracing infrastructure a lot better than Console.WriteLine. Tracing gives you many different options for where the trace messages can go, as well as being able to turn them on or off. You can also set different levels of tracing output so that you can adjust how much logging actually gets done. The built in tracing in .NET is very flexible, and is well worth the investment to learn.
Here are a couple of references to help you get started:
http://msdn.microsoft.com/en-us/library/ms228993.aspx
http://msdn.microsoft.com/en-us/library/ms228984.aspx
http://www.code-magazine.com/Article.aspx?quickid=0409081
HTH!
Chris

You could go to Tools | Options | Look for Debugging, General, Choose the Redirect all Output Window text to the immediate window, or try to log the console-intended output to a file and view it there instead.

Is there a way to *completely* disable Edit and Continue?

I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike

Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".

Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam

Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.