Removing dependency on ImageHlp.dll

Removing dependency on ImageHlp.dll


We're trying to get a Fortran dll to run on a PC running the LabVIEW real time 12.0 operating system. The dll is compiled using Visual Studio 2008 with Intel Fortran v10.0.025. We've successfully compiled and ran a simple Fortran dll on the real time computer. However, we can't get a more complex Fortran dll to successfully run on the real time computer (it works fine on Windows 7). We've spoken with technical support from LabVIEW, and their response was that the real time computer does not have all of the standard libraries that are normally available on Windows computers. Using Dependency Walker and LabVIEW's DLL Checker, we've discovered that the complex Fortran dll loads libifcoremd.dll as a dependency, which in turn loads imagehlp.dll as a dependency and we've identified imagehlp.dll as the culprit. Just placing imagehlp.dll and its dependencies on the real time computer reports a generic error message that there was an error loading a dll. Is there a way to cull out imagehlp.dll while keeping the functionality in libifcoremd.dll?

We've tried eliminating the dependency on imagehlp.dll by compiling in Release and disabling all debug and tracing options, but imagehlp.dll is still listed as a dependency. We've also tried setting "Ignore Specific Library" to ignore imagehlp.dll, but it gets loaded anyway. 

We've also tried statically compiling the runtime libraries. We did this by changing the project settings to compile as Multithreaded. Then we added libifcoremt.lib and libmmt.lib under "Additional Dependencies." However, there is no imagehlp.lib to statically compile, so imagehlp.dll is still a dependency. We tried setting imagehlp.dll to be delay loaded and then included delayimp.lib. But it is still failing to pass DLL Checker.



16 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

From what I can see, this dependency is automatically added by the linker and you can't turn it off. My recommendation would be to write your own dummy imagehlp.dll with its three entry points that just return, and put it alongside your exe.

I would say that the "DLL Checker" you are using needs to understand about delay loaded DLLs.

Retired 12/31/2016

Use MS Depends and verify what values imagehlp.dll has in the following attributes of PE header:

- Image Ver
- OS Ver
- Subsystem Ver

These values should be "compatible" with the operating system you're using. For example, in case of a 32-bit Windows XP these values are as follows: 5.1, 5.1 and 4.0 and it matches to a generic OS version 5.1. In overall, these numbers should be less or equal to OS number.

Another things are:

- imagehlp.dll has two internal dependencies on msvcrt.dll and dbghelp.dll

- if libifcoremd.dll uses some functions from imagehlp.dll then a simple stub-like DLL won't help

imagehlp.dll is used by Fortran only for traceback. You get the reference to it no matter what you do. Delay load does work, but the "DLL Checker" tool Arthur is using doesn't treat missing delay-load DLLs as unimportant.

Retired 12/31/2016

Since the real time computer isn't a Windows os, I wouldn't expect changing the attributes of imagehlp.dll to make a difference. The real time computer also doesn't have msvcrt.dll or dbghelp.dll.

If imagehlp.dll is just used for tracing and debugging, then I think we can do without it. We're trying to create our own dummy imagehlp.dll right now, which is taking more time than expected since its interface uses a lot of typedefs and structs.


You don't need to worry about the interfaces, since it should never be called. Just have the functions with enough dummy arguments to get the @n right and have it return 0.

Retired 12/31/2016

>>...imagehlp.dll is used by Fortran only for traceback...

If that option is Off then the Arthur's application should work. If it doesn't ( what Arthur is reporting ) then something else is wrong.

Arthur, are there any error messages when you try to execute the application?

>>...LabVIEW's DLL Checker...

Could you make a screenshot for review?

>>...Since the real time computer isn't a Windows os...

Any details on what is it?

The real time computer is LabVIEW Real-Time 12.0, and I think it is based on Phar Lap ETS.



Steve Lionel (Intel) wrote:

You don't need to worry about the interfaces, since it should never be called. Just have the functions with enough dummy arguments to get the @n right and have it return 0.

I'm not sure what you mean by "having enough dummy arguments to get the @n right." I thought the input parameter types in the dummy functions had to precisely match the actual functions.


Only if the routine actually gets called and does something with the arguments. For your purpose, it should be sufficient to have a DLL of the right name with entry points of the right name, so that it satisfies the "DLL Checker".

Retired 12/31/2016

Writing that stubbed imagehlp.dll worked! Our fortran dll is running properly on our real time computer now. Thanks so much!!



Retired 12/31/2016

>>Writing that stubbed imagehlp.dll worked! Our fortran dll is running properly on our real time computer now...

I'm impressed that it worked and thanks for the update!


I am encountering the same issue and Google led me to this very relevant thread! I am trying to use my IVF dll on a NI PXI real-time non-windows computer (likely similar to Arthur's). Using the "Multithreaded" option I statically include all troublesome dependencies but imagehlp.dll, which I can't get rid off.

I got hold on the header file and am thinking on how to create the stubbed dll, unfortunately my experience in C is very poor, I got no idea of the number, name and type of the arguments to replicate by reading it... Would you be keen on sharing the file with me? Or perhaps help me to build my own? 



Problem solved! I'm updating this post for other users... I feel sorry that it does not show the best of IVF. I agree that it should rather be a Labview forum thread.

gfortran in MinGW using the -shared -static-libgcc -static-libgfortran flags outputs a fully compatible (and smaller) dll for NI real time targets. I did not take the risk to spend time on creating the stubbed imagehlp.dll because the NI Dll Checker was also pointing out a unsolved dependency upon the function "GetFileAttributesExA" in kernel32.dll, so it might not have worked anyway. Dependency walker actually still shows me this dependency in the gfortran-compiled dll, but it is for some reason not an issue anymore in DLL Checker, and the dll is successfully deployed on the RT target. Perhaps it was a cross error with imagehlp.dll...

Another possible solution which I haven't explored could be to use ifort in MinGW with the "nolib_inline" flag (only available on the Linux version) no to inline the math intrinsic functions causing the dependency upon libifcoremd.dll, and including those functions by linking manually libmmd.dll (for instance). Don't know if that sounds reasonable.

Leave a Comment

Please sign in to add a comment. Not a member? Join today