DLL NOT FOUND (but only on certain systems???)

  • Thread starter Thread starter ags5406
  • Start date Start date
A

ags5406

I have an application written in VB.NET that calls functions in a
FORTRAN .DLL. All compiled (release for VB.NET and FORTRAN), with
the .EXE and the .DLL and other support files all in the same folder.

On my PC it works absolutely fine. No issues whatsoever. It also
works perfectly on SOME (most?) other PC's in my area.

However, there are some PC's in my area where the .EXE simply refuses
to find the .DLL, despite the fact that the setup is identical (single
folder on the desktop that contains all necessary files). The .DLL is
in the same folder as the the .EXE. The error I receive is:

Unable to load DLL 'TEST.dll': This application has failed to start
because the application configuration is incorrect. Reinstalling the
application may fix this problem. (Exception from HRESULT: 0x800736B1)

Unfortunately, I am not able to debug the problem because it works
perfectly for everyone when I compile the .EXE and the .DLL in debug
mode.

Any suggestions? I am going crazy here... Thanks...
 
ags5406 said:
I have an application written in VB.NET that calls functions in a
FORTRAN .DLL. All compiled (release for VB.NET and FORTRAN), with
the .EXE and the .DLL and other support files all in the same folder.

On my PC it works absolutely fine. No issues whatsoever. It also
works perfectly on SOME (most?) other PC's in my area.

However, there are some PC's in my area where the .EXE simply refuses
to find the .DLL, despite the fact that the setup is identical (single
folder on the desktop that contains all necessary files). The .DLL is
in the same folder as the the .EXE. The error I receive is:

Unable to load DLL 'TEST.dll': This application has failed to start
because the application configuration is incorrect. Reinstalling the
application may fix this problem. (Exception from HRESULT: 0x800736B1)

Unfortunately, I am not able to debug the problem because it works
perfectly for everyone when I compile the .EXE and the .DLL in debug
mode.

Any suggestions? I am going crazy here... Thanks...
Click to expand...

Is this an ActiveX dll? Is it registered correctly?
 
ags5406 said:
I have an application written in VB.NET that calls functions in a
FORTRAN .DLL. All compiled (release for VB.NET and FORTRAN), with
the .EXE and the .DLL and other support files all in the same folder.

On my PC it works absolutely fine. No issues whatsoever. It also
works perfectly on SOME (most?) other PC's in my area.

However, there are some PC's in my area where the .EXE simply refuses
to find the .DLL, despite the fact that the setup is identical (single
folder on the desktop that contains all necessary files). The .DLL is
in the same folder as the the .EXE. The error I receive is:

Unable to load DLL 'TEST.dll': This application has failed to start
because the application configuration is incorrect. Reinstalling the
application may fix this problem. (Exception from HRESULT: 0x800736B1)

Unfortunately, I am not able to debug the problem because it works
perfectly for everyone when I compile the .EXE and the .DLL in debug
mode.

Any suggestions? I am going crazy here... Thanks...
Click to expand...

I seem to remember a runtime dll that we needed to distribute like f77.dll
or f90.dll, that had to be installed into the \windows\system32 folder.
Occasionally we ran into issues with permissions installing there. It's been
years, and your environment may be quite different than we had at the time.


Isn't there some runtime library such as f77.dll or f90.dll that you need to
distribute with the
 
Not ActiveX.

There are Fortran runtime DLL's, and they are included in the
distribution.

There is definitely something very screwy going on. Last night I
updated the .TEXT of a label on one single form by adding ONE, just
ONE extra character.

For example, the lblTest.Text = "ABC" was changed to lblTest.Text =
"ABCD". Literally the only change I made to the code. Recompiled and
reran and then magically, all of a sudden, all of my problems have
disappeared. The package seems to work correctly on all PC's in my
area now.

One thing I did notice is that my executable increased in size from
1408 KB to 1552 KB. How or why adding one single character to the
code (which is hundreds of thousands of lines in total) could increase
the executable size by 10% is beyond me. And why adding one single
character to the code would fix a seemingly unrelated problem is also
beyond me.

Methinks I have a gremlin. I have always believed that "the program
only does what you tell it to do", but this is the first time I'm
starting to doubt that.

All of my projects are under source control (we use CVS), so I am able
to ensure which version I am using. I am able to REPEAT the problem
with the first executable and I am able to REPEAT the success with the
second executable (with the one extra character in the code).
 
Back
Top