4

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

Mike
  • 4,542
  • 1
  • 26
  • 29
  • Sadly, no. I've tried everything from modifying calling conventions to writing a C wrapper around the Fortran, then wrapping that! *Sigh* Good luck to you, though, and if you get any results, please do leave an answer below! Thx :) – Mike Sep 12 '09 at 15:53
  • I'm also having the same problem. Did you find any solution or workaround for it? – Alex Sep 29 '10 at 12:38

5 Answers5

22

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?

EDIT: In more recent versions the option is called: Enable native code debugging (thanks Qwerty01)

EDIT: It also seems to help in VS2008 (@Deacon Frost), VS2010 (@Alxandr).

MartyIX
  • 27,828
  • 29
  • 136
  • 207
1

I am using Visual C# 2010 Express. I was able to stop the vshost32 crashes by navigating to Project -> Properties. I clicked on the Debug tab and unchecked the "Enable the Visual Studio hosting process" checkbox.

Matt G
  • 81
  • 2
1

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

Shea
  • 11,085
  • 2
  • 19
  • 21
  • 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 .vshost.exe isn't used. – Mike Apr 09 '09 at 20:19
  • 1
    Thanks for the help - still crashing, but I appreciate the debugging help! – Mike May 08 '09 at 16:14
1

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.

Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
  • 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 Apr 09 '09 at 20:28
  • 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? – Dirk Vollmar Apr 09 '09 at 20:35
  • 1
    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 Apr 09 '09 at 21:08
  • 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 – Dirk Vollmar Apr 09 '09 at 21:39
  • Not a bad suggestion. I did a bunch of trial & error stuff, and I've decided that I'm just gonna run the dang thing outside of Visual Studio. I can't debug this particular piece of the app, but life goes on. thx again! – Mike May 08 '09 at 16:15
0

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.

patrick
  • 16,091
  • 29
  • 100
  • 164
  • 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 Apr 29 '09 at 14:47