Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

vfproj.dll crash

Martin__Paul
New Contributor I
1,197 Views

I have a large (50+ projects) Visual Studio 2008 solution containing approximately 35 Fortran projects and 15 C++. The majority of these generate shared libraries that are linked into a handful of exes. I am using IVF 11.1.060.

About one build in four calling devenv.exe from the command line generates an unhandled exception resulting in DW20 (Windows Error Reporting tool) and an entry in the app event log with the following content:

Event Type: Error
Event Source: Microsoft Visual Studio
Event Category: None
Event ID: 1000
Date: ...
Time: ...
User: N/A
Computer: GHBUILDBLADED
Description:
Faulting application devenv.exe, version 9.0.30729.1, stamp 488f2b50, faulting module vfproj.dll, version 11.1.3470.2008, stamp 4b5f3e57, debug? 0, fault address 0x00031de3.

The frequency of this problem increases when multiple parallel builds are enabled, so I have reduced the number of builds to 1.

I found a related post here describing the same issue in VS2005:http://software.intel.com/en-us/forums/showthread.php?t=67849

One similarity between my setup and that of the post above is that I have a top-level directory containing a C++ header file and a Fortran .fi file that define the current build type and do nothing else. At build time the preprocessor conditionally excludes code that does not belong to the defined type. The build effectively rebuilds the solution for the number of targets (build types) defined. However since all components are rebuilt and we are not using precompiled headers anywhere I am unsure why this should cause a circular dependency problem (ref. Jim Dempsey's post).

We are very keen to take advantage of parallel builds (or at least have stability in single-process builds). Is there is a fix for this in more recent Fortran-MVS integration libraries? As per Jim's suggestion I will try adding common include files to their own project and setting as a dependency of projects that included the files, but would prefer to avoid this if there is an official fix.

Many thanks.

0 Kudos
2 Replies
Steven_L_Intel1
Employee
1,197 Views
I have seen occasional reports of this problem but we haven't been able to reproduce it. I have routinely done 8-project builds in parallel without issue, though not using the preprocessor. I have seen other reports specific to preprocessing where some sort of file access error is given.

I can say that we will have an all-new implementation of the Fortran project system for VS2010 later this year (the VS2010 implementation in the 12.0 compiler is substantially the same as 11.1.) If you are interested in testing this, let me know. (It would require that you have VS2010 since you have mixed-language applications.)
0 Kudos
Martin__Paul
New Contributor I
1,197 Views

Thanks for that. We do plan to migrate to VS2010 this year, so would be keen to give v12.0 a go at the same time.

In the mean time I'll try adding the common header\interface files to separate projects and test with parallel builds.

0 Kudos
Reply