views:

762

answers:

4

Hi all,

I'm using a VS 2005 app to interface against an unmanaged (Fortran) DLL. When I run the compiled executable straight from the command line, everything is fine - the DLL can be accessed, and I can work with the functions in the DLL.

Unfortunately, when I launch the app from VS 2005, I get a popup stating "vshost32.exe has stopped working" and no useful debugging information.

Has anyone experienced this behavior, or know why this might be occuring? I can't figure out why it would run fine when launched stand-alone, but not via vshost32.

(One last note: I am using .local files to force registered dlls to be used from cwd, but this particular dll is not registered. I'm just noting it here in case it helps.)


Thanks very much,

Mike

+1  A: 

Not sure but you can disable use of the visual studio hosting process from Properties -> Debug

Arnshea
Surprisingly, had no effect - still crashes in the same way. Do you know what exact effect this setting has? I think vshost is still used, but the <appname>.vshost.exe isn't used.
Mike
Thanks for the help - still crashing, but I appreciate the debugging help!
Mike
+1  A: 

Might be that there is an unhandled exception. You could try to add the following code to handle all uncatched exceptions:

static void Main()
{
  // Add a handler for the UnhandledExceptionEvent
  AppDomain.CurrentDomain.UnhandledException +=
    new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

  Application.EnableVisualStyles();
  Application.SetCompatibleTextRenderingDefault(false);
  Application.Run(new Form1());
}

static void CurrentDomain_UnhandledException
     (object sender, UnhandledExceptionEventArgs e)
{
    try
    {
        Exception ex = (Exception)e.ExceptionObject;

        MessageBox.Show(ex.ToString(), "Error", 
              MessageBoxButtons.OK, MessageBoxIcon.Stop);
    }
    finally
    {
        Application.Exit();  
    }
}

The reason for the underlying problem is that you might have a different working folder when debugging so that your native library is not found.

0xA3
Unfortunately, no unhandled exceptions were caught. Also, I'm setting the cwd explicitly in code before the calls to the unmanaged dll. Still baffled! Thanks for the help tho.
Mike
It assume that the external dll is already resolved before you have the chance to change the working folder. I couldn't find any documentation when this resolution happens but it might be at the time the assembly is jitted?
0xA3
Well, the really strange thing is that I can call _some_ of the functions in the unmanaged DLL, just not all of them. erk!
Mike
Maybe you have a different version of the dll on your path during runtime? Or certain funtions in your dll load other libraries dynamically which are not on your path during runtime
0xA3
Mike
A: 

download dependency walker http://www.dependencywalker.com/ use it to open up your dll, and see if it relies on other dlls that are not present in that folder.

iterationx
thx for the suggestion! unfortunately, as it runs fine from command line, I can rule out a dependency issue - there's just something about using the .vshost. executable that is mucking up somewhere. *sigh*!
Mike
+1  A: 

I had problem with crashes of vshost32.exe the problem vanished when I checked the checkbox:

Properties -> Debug -> Enable unmanaged code debugging

Does it work for you?

MartyIX
This fixed my vshost32.exe crashing problem.
Dave