I've got to demo a project for my degree tomorrow and after running my final build on other machines it seems it only works on mine.
The error is:
EventType : clr20r3 P1 : userfriendlylatex.exe P2 : 1.0.0.0
P3 : 447b4557 P4 : system.windows.forms P5 : 2.0.0.0 P6 : 4333aefa
P7 : 1979 P8 : 2 P9 : pszqoadhx1u5zahbhohghldgiy4qixhx
This seems to be an unhandled exception but how do I find where this is
Really apprecaite any help.

URGENT! Runtime error
David Walp - Microsoft
Well I now know it's an unhandled file not found exception but for what I can tell all the files are there. It did run once on a machine with VS 2K5 but then i uninstalled VS and reinstalled it and it has about 3 errors relating to one of the dlls I have used. They are present as they are on my own computer so I don't see where those are coming from. I'll continue to look at the problem when I had more time and post a solution on this thread incase others have similar problems.
Thanks for your help.
AlexSl
Try putting the PDBs from your binaries into the same directory and run it again to get a call stack or something that you can work with. The PDBs are, I believe, automatically generated even in release builds but if not go to your project settings, Build settings, Advanced button, Debug Info - PDB-only.
Michael Taylor - 5/30/06
LockyBoy1
Unlikely that it is a build problem. If you were missing a file or something then you should have gotten a better message. .NET 2.0 is installed on the machine right If you uninstall VS2005 does the problem start occurring again Were you able to get a better call stack in the error log after copying the PDBs over You don't need the debugger for that.
You could use the remote debugger to debug against a remote machine. You'll need a few binaries on the remote machine but not the entire debugger. This should permit you to debug the problem. Alternatively you could simply try using Trace to trace some events until the app blows up to help narrow down your problem.
Michael Taylor - 5/30/06
Vikram Karumbaiah
Ricky Kelley
cdbrown
You don't open them at all. When an exception occurs and the debugger runs, or if Dr. Watson generates a log, then it will first search for the corresponding PDB for the binary that cause the crash. If it finds the PDB then it'll use the symbol API to build the call stack information. The PDB contains the information necessary to build this information. If you are on the .NET side and an exception occurs the PDB will help the runtime build an accurate callstack by providing it the symbol names. In the unmanaged world this is the only way to get symbol information. In .NET the metadata is still available but depending on how the code is compiled the call stack still might not be that useful. With the PDBs in the same directory run the app and see if you can get a better log of what went wrong.
Michael Taylor - 5/30/06