CODEWITHSUNDEEP
.netf#dll
user1715547
user1715547

Reputation: 21

Distributing an F# application (crash on startup)

I have an F# 3.0 application that works fine on the computer it was built on. I have copied the application, FSharp.Core.dll and other dlls that seemed relevant to a Windows Server 2003 machine that has .net v4.0 installed on it.

The application starts correctly, but crashes very soon afterwards. The message is "An unhnadled Microsoft .NET Framework exception occurred in theapp.exe [some number that is different every time]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled (....)"

The message is the same if I remove FSharp.Core.dll. In that case the application does not even get as far as its initial message. This makes me think the cause might be that some other dll is missing.

I have tried Dependency Walker, but it does not appear to mention even Fsharp.Core. It does complain about some dlls missing that Google suggests don't matter (e.g. something with a shim/device manager in the name). I also tried starting Fuslogvw.exe but it just sits there without logging any output whatsoever. I cannot install MSVC on the target computer.

I will be most grateful for any suggestions as to what to try. Many thanks.

EDIT: .net reflector does not report anything obviously wrong either ....

Upvotes: 2

Views: 454

Answers (2)

Storstamp
Storstamp

Reputation: 423

If you have problems with the dependencies, you may try to use --standalone

as a compiler parameter. If you only want to distribute a simple application, this may help.

If you still have problems, you may use Process Monitor to identify what files and registry keys your application tries to read/load but fails. Remember to set a filter in the monitor to only your application, otherwise your system will come down to crawl, trying to log basically everything.

Upvotes: 0

Asti
Asti

Reputation: 12667

Try and attach to the AppDomain.UnhandledException event at the very beginning of your entry point. i.e., AppDomain.CurrentDomain.UnhandledException.Add(fun e -> ... log error ...) to try and capture what the error is before your application unloads.

If your application is a windows application, you can also attach a handler to Application.UnhandledException to attempt the same.

Another option is to copy the Remote Debugging redistributable to the target machine, and connect to it from where your source resides. This will allow you to step into the point in code where the crash actually happens.

If your application is a multi-domain host, then the remote debugger might be your best bet.

Upvotes: 3

Related Questions