- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My program has a small exe stub that calls the computational dll. It works fine on my development computer. When I install on a test machine, I get the error message "The application failed to initialize properly (0xc0150002)." I have similar problems loading that sameDLL from my VB.Net application using LoadLibraryA (again, works fine on dev machine).
I installed dependency walker and ran. Found that I needed a few IVF dlls, which I included: libifcoremdd, libmmdd, msvcr80D. I also installed the C++ redist available from MS.
I've attached the dep walker file, in case you have a chance to pull it up and view it.
The application is compiled in debug mode--I'd like to distribute that way, at least initially.
I'm using IVF 11.0.061.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. The manual does have some text on redistributing applications. Dependency Walker is the tool I recommend, but you need to know that the MSVC DLLs have to come from the Microsoft redistributable installer. We are in the process of building our own redistributable installer - not there yet,
2. No, unfortunately. Errors that are detected by generated code, such as array bounds, are not "catchable". There is an open feature request on this - I'll add your name to the list.
3. Not directly. There is SIGNALQQ which will let you be notified when an exception occurs, but you can't really recover from it. The Building Applications part of the documentation has a long chapter on exception handling which is worth a read. In some cases, you may need to wrap your Fortran code with some C++. For floating point exceptions in particular, we now support the Fortran 2003 IEEE modules which allow you nice control over the IEEE floating point exception environment.
I am curious - what prompted you to switch from Absoft to Intel?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Remove the MSVCR80.DLL that you added - that should come from the MSVC redistributable package only as it has to be installed as part of an assembly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, I removed that file from the directory, but still get the same error message when trying to load the DLL. I will try to create a simple Hello World application and get it to work on that computer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, I removed that file from the directory, but still get the same error message when trying to load the DLL. I will try to create a simple Hello World application and get it to work on that computer.
I created a Hello World EXE that ran fine on test computer--no dependencies. Then I added a simple call to a routine in myFortran DLL and the "failed to initialize" error occurred; again the same test program runs fine on my development machine.
So it appears that a IVF dependency is not there still. Is there a runtime installer for IVF dependencies? Am I prohibited from distributing Debug releases? Is there any way to get more information about exactly why the app is failing when the CLL routine is called?
More information: I've tried my best to utilize the Dependency Walker program to see what else might be needed. When I removed the MSVCR80D.dll file as you suggested, DW reports it as missing and needed; this despite the fact that I installed the Microsoft Visual C++ 2008 redistributable (x86 9.0.30729.17). When I restore that file, the only warning icon in DW is for MPR.DLL which DW specifically says is not a problem. However the log says:
Error: The Side-by-Side configuration information for "c:program filesepdriv1 v1.2RIV1H.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
So I'm really stuck.
Thanks in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, I'm kinda answering my own questions. I recompiled the Fortran DLLs in release mode and it worked fine on the test machine. The debug libraries were being referenced. I suppose they are non-distributable, but it is curious that they didn't show up using DW.
I liked IVF because when a runtime error occurred, a decent dialog (albeit too large) would appear rather than the DLL just crashing without warning. I need to investigate other means of error trapping.
Some of my previous questions still are pertinent, and I'd appreciate enlightenment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, you guys have to cut me some slack! I'm coming from Absoft and things were much more difficult there! :)
All I need to do is turn on on error trapping but still compile as a release version; the big error dialog still appears, but dependencies are still not a problem.
IVF is really good!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Slack duly cut. What do you still need help with?
You are correct - the debug DLLs are not redistributable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to finish up this posting, please answer the following questions:
- What is the best way to determine IVF dependencies and resolve them?
- Does the help manual address this issue and/or list possible dependencies?
- Is there an Intel install package available?
- Is DW the best way to go?
- Are there also equivalent SIGNALQQ signals that will catch array out of bounds, etc.?
- For release code, are there other mechanisms to trap errors that may occur while loading a DLL or inside the DLL? Absoft was bad in that if the DLL crashed the entire application just went away, and there was no opportunity to write a log file or prompt the user. For example, does IVF have something similar to TRY/CATCH?
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. The manual does have some text on redistributing applications. Dependency Walker is the tool I recommend, but you need to know that the MSVC DLLs have to come from the Microsoft redistributable installer. We are in the process of building our own redistributable installer - not there yet,
2. No, unfortunately. Errors that are detected by generated code, such as array bounds, are not "catchable". There is an open feature request on this - I'll add your name to the list.
3. Not directly. There is SIGNALQQ which will let you be notified when an exception occurs, but you can't really recover from it. The Building Applications part of the documentation has a long chapter on exception handling which is worth a read. In some cases, you may need to wrap your Fortran code with some C++. For floating point exceptions in particular, we now support the Fortran 2003 IEEE modules which allow you nice control over the IEEE floating point exception environment.
I am curious - what prompted you to switch from Absoft to Intel?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Absoft: don't get me started! Was recommended by colleague, and resulting code was very fast compared to what we had before, so performance was great. Their editor is terrible and debugger is worse. We wasted so much time trying to figure out the quirks of their compiler settings too. Then they did an upgrade a few months after we bought and wanted us to pay full price for new version
At first we were put off by IVF's separate debugger (I didn't understand that the VS debugger was perfectly adequate for almost everything we were doing). Benchmarking initially showed Absoft being faster than IVF for our app, but we are writing large binary file and found that if we set IVF BUFFERS to non-default value, performance is somewhat better then Absoft.
Tech support has been fantastic, especially compared to Absoft, which appears to pay somewhat less attention to the Windows market. Thanks alot.
BTW: Absoft caused same difficulty with runtime dependencies--would be good if you could add an KB article clearly discussing what you and I just went through.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page