VB.NET prog crashes on any other than dev machine

[Mr. Black]

Hey guys,

Im stumped.

 

Every time I run my program on any other machine than the one I developed the program on it hard crashes (Program has stopped working dialog).

 

Anyone help?

[Mr. Black]

Surprised by all the views and noone knows...

Anyways, I figured it out. I forgot to include a dependency.

[Aergan]

Might be worth error handling it.

[Mr. Black]

  On 11/12/2014 at 11:13, Aergan said:

Might be worth error handling it.

 

Can't. Dependency missing causes a hard crash, not an exception dialog.

Almost everything else that can error is in a Try...Catch statement.

[Kami-]

  On 11/12/2014 at 11:08, Mr. Black said:

Surprised by all the views and noone knows...

Anyways, I figured it out. I forgot to include a dependency.

 

I'm surprised you expect a program to work without its dependencies.

[Mr. Black]

  On 12/12/2014 at 11:51, Kami- said:

I'm surprised you expect a program to work without its dependencies.

 

Um, I don't. I just didnt know what was causing the error until I looked thru things and found it wasn't copying the dependency.

[Dermot]

You're try/catching your own functions and events, have you attached the debugger and caught unhandled exceptions yet?

 

..i mean for example .. like AppDomain.CurrentDomain.UnhandledException or Application.ThreadException

[+Raphaël G. MVC]

A neat program to catch these types of problems for .NET 4.x apps on computers that don't have visual studio or a debugger: procdump from Micosoft (http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx)

 

It is to be launched from the command prompt. If you launch it with the following options, it waits until your app starts and then throws all exceptions in the command window:

 

procdump -e 1 -f "" -w -ma nameofyourprogram.exe

 

You can also use procdump to create a dump file on the machine which has issues. Then by opening that dump file in visual studio on your dev machine, you can see where in the code a problem occured.

Very useful to debug problems at customers when you don't have a debugger on the failing machine.

[Mr. Black]

Raphael,

 

That will be a MAJOR time saver in the future - thank you very much (PS the issue is already fixed - for the 2nd time people, it was a missing dependency i forgot)

 

Where do you open the Dump file in Visual Studio?

[+Raphaël G. MVC]

  On 09/01/2015 at 18:45, Mr. Black said:

Raphael,

 

That will be a MAJOR time saver in the future - thank you very much (PS the issue is already fixed - for the 2nd time people, it was a missing dependency i forgot)

 

Where do you open the Dump file in Visual Studio?

 

To open the file in visual studio, just do File -> Open -> File (as easy as that )

I've had the missing dependency problem several times myself. When putting together the installer for my applications, after adding a new dependency, I sometimes forget to add that dll to the installer routine.

 

Another tip concerning procdump. Make sure you always have pdb files for the software you put on other computers. Visual Studio needs the pdb's to be able to break into the code when loading a dump file which was created on another computer. Compiling pdb's from the same code afterwards, doesn't help. You need the pdb's that were compiled together with the binaries you installed on the "other" computers.