On going Visual Studio 2005 ( including SP1) problems

On going Visual Studio 2005 ( including SP1) problems

We are using VS 2005 + Intel 9.1.034 compilers on a large project with multiple win32 and x64 configurations, and frankly, it has become a nightmare. Here is a laundry list of issues with this (admittedly) complex C++/MFC project

- Visual Studio crashes repeatedly ( 10 times a day). This happens on all three development machines ( XP, 2G RAM). Every time we exit Studio it crashes now (SP1). Only with this project.

- Visual Studio crashes repeatedly in 'batch mode'

Since you cannot batch build a intel C++ visual studio project using vcbuild, you have to use "devenv" to batch build. Our nightly builds crash every night now.

- Source code control integration seems to get confused by the .icproj/.vcproj dichotomy. We have completely disabled all source code control integration and use SourceSafe as a separate application.

- Read-only .icproj files get modified ( and the settings get confused) by the Intel VS Integration tool. This is somewhat random, but it is hugely frustrating, as you open a project, build, and find that the build fails. The offending project will now have a writable and modified .icproj which needs to be manually replaced by the version in source control. No warning is given, the READ-ONLY file just gets changed.

- When building the projects , randomly some C++ .obj files will be created by the Intel Compiler with 0 bytes size, and then the link phase will fail with "multi-file optimization error". One needs to either restart the build or manually recompile single files. This completly breaks our automated build.

- The FIASCO with SP1 and the fatal link errrors with any code compiled with Intel Compilers and /Zi. 034 still has not fixed the problem totally, we now get "debugging information corrupt" in debug builds

I have submitted all these issues to Premier Support, but of course, the issue gets stuck in "waiting for customer" as they cannot reproduce the problems unless I send 2G of project/proprietary source files...

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

Could you specify which problems arenew with 034, which ones are existing?


Let me preface this by stating I don't work for Intel nor MS. I currently use VS 2005 and IVF 9.1.032. Some time back (18 months) I was using VS 2003 and IVF 8.n.mm.

At that time, I too was experiencing build problems where build would intermittantly crash. Usually a fatal error from Devenv reading or writing incorrect addresses. This happened with Build->Debug. I had a 50/50 chance of crash. The finger pointing between Intel and MS went back and forth for several months and over several updates. Then for some reason I installed VS on a different system, copied my application files over *** but did not copy the solution and project files. Instead I re-entered the solution and project files by hand (~10 projects, ~750 files). No problems with Devenv. I then deleted the solution and project files on the main development system, (re-booted to flush the deletes), then re-created the solution and project files. And "ta da" no problems with Devenv. What this means... I haven't a clue. But I haven't had problems since.

I've seen the 0 length file thing before. From my recollection the file is open in multiple places at once (causing write protect) but where one of the opens is a Create file (which forces the file write pointer to byte 0). The create succeeds (making file 0 bytes) but writes are inhibited. I cannot say for sure, but I think the problem had to do with having the project open in multiple different solutions at the same time.

These were old problems. But perhaps the problems between then and now are related.

Hope this helps

Jim Dempsey


Hi Jim,

You have IVF 9.1.xxx, do you mean ICL 9.1.xxx? There was a build problem with icl, but it should have been fixed.


No, I have Intel Visual Fortran. The problem I used to have (over a year ago) was a problem with Devenv crashing. The description of the original post sounded very similar. Although I no longer have the problem, this is not conclusive that the problem was eliminated. Some times problems (symptoms) go away without a fix.

In my case, the problem occurred running debug sessions.

In IDE making edits
F5 to compile and run
Stop to IDE
end loop

I used to have a 50/50 chance a Devenv crash would occurs after F5.
Strangely, sometimes the Devenv crash would be immediately and other times maybe 30 seconds or moreinto the debug session. "We're sorry but your application... (devenv) and will have to be closed".

That was really annoying. Like I said, I haven't had that problem for a year now.

At first thought you might think the thread's poster's problem would not be similar to the problem I used to have. After all he is compiling from a batch file. However, also note that his compilations are being made by way of the batch file calling devenv to perform the compilation. In my case, the IDE (running in Devenv) called devenv (recursive) to perform the compilation. As explained before, in my opinion, this is related to the null file situation where on application has a file open for exclusive write (but permits) another application to create new file of same name, then inhibit write. This, again in my opinion, was a sequencing problem between the dependency checking process in devenv and the compilation process attempting to create the file on which the dependency check was being made. i.e. there was a race condition amongst:

devenv file dependency check
compiler producing file of dependency check
operating system performing lazy write(close) or other?

Just a suspicion.




The problem you describe had to do with the Fortran Debug Expression Evaluator and an issue relating to when DLLs get loaded and unloaded. It is unrelated to the build problem described here and that problem was fixed.

Steve - Intel Developer Support

All the problems except the Link Errors have persisted through various Intel 9.1 Compiler versions and the frequency has not changed since upgrading to SP1 and compiler 034.

The link errors are the only new problems that have been caused by 034/SP1

I can live with the Link Errors as they are not fatal. The big problems are

- DevEnv crashing in batch mode when building these projects.

- read-only .icproj files getting changed by the Intel VS integration tool. The tool seems to get confused between x64 and Win32 configurations, and the result typically is that the x64 configuration ends up with some settings from the Win32 configuration. The .vcproj is never touched.

- In a project build the ICL compiler will create (randomly) 0 byte sized object files causing a "multi-file-optimization errror" an link time

(see thread http://softwareforums.intel.com/en-us/forums//topic/47133)

As I noted in that thread, you have to go back and manually right-click compile the offending files.

the "devenv" crash when batch building in particular is a real problem for us. VS no longer exports (n)Makefiles, and vcbuild does not understand .icproj. An "iclbuild" would be really nice to bypass VS.

These problems occur on 4 build machines. All clean Windows XP professional machines with 2G RAM.


Could you report each of your problems to https://premier.intel.comso we can track/fix each problem? It's ok if you couldn't provide the testcase. But if you can give more detail steps, we could try to duplicate the problem.



All problems have been logged into premier support. All problems are "waiting on customer" as I cannot send my projects beacuse of their size and complexity, and I cannot reproduce the issues in a self-contained example.


As a diagnostic exercise, see what happens when you burn your project file to CD-ROM then build using the immutable project files. Apparently write protected is not sufficent.

The intent here is not necessarily to give you a work-around but to force some sort of error, hopefully with a finger pointing back at the offending code.

On this topic, I cannot understand why a vendor's product would purposely go out of it's way to modify a user file that is explicitly set to Read Only without asking for permission.

Jim Dempsey



Good idea about the read-only media...

I tried to make a point in my premier support discussion that Intel was to look for some mechanism where the Intel integration tool must ignore or unset the R/O flag.


Visual Studio could be the culprit as well or in addition to the Intel integration tool.

My guess as to why the tool is unset ting the R/O flag is because when you install from the CD-ROM (or DVD) that if "demo" applications arecopy to your system that the resulting project files would be R/O. Intel, or more likely Microsoft may have received a lot of complaints that the demos wouldn't run (due to being R/O). Their "fix" was to rename the project files to same name but with R/W attributes. In my opinion, this was a "crock" fix. The correct way to handle this is for the Installer to change the R/O to R/W on the files that need to be changed. VS (and integration tools) should be able to handle R/O files, including project and solution files. And if VS requires some R/W capabilities, it should do so by way of an intermediary file (not necessarily in the project directory, which may be on R/O media).

Jim Dempsey



There's a fix for changing the .icproj's read-only attribute when doing the batch build with "devenv". This fix should be in the next 9.1 update.

Using the CD is a great idea for testing. THANKS!


If anyone is any doubt about this bug, here is a typical example in attached JPG. I turned on the warning in options. The IDE integration thinks .vcproj is later than the .icproj ( it should not be, it may be a result of some time stamps from SourceSafe) and just quietly overwrites the existing R/O .icproj, leaving it R/W.

Please, please, stop the IDE integration from modifying the .icproj when it is R/O!


Downloadimage/jpeg intel.jpg43.26 KB


The behavior we want is

If the .icproj is R/Okeep it R/O

Do not rename to R/W

Do not rename to R/W, modify, rename back to R/O

Do not provide an option switch change from R/O to R/W

If the user needs R/W on the project then they must make an extra, and explicit, action to convert from R/O to R/W.

A userhas to takeexplicit action to make the file R/O. If they went through this extra effort to make the file R/O, then it is only appropriate for the tools to abide by the wishes.

Think of this asthe door lock on the stall in the bathroom. Do you want the lock to work or do you want it to automatically unlatch anytime someone pulls on the door?

Jim Dempsey


Let me second Jim's comments. The IDE integration should never , ever, overwrite a R/O .icproj.

This problem also highlights a failure in the Premier support process. I reported the issue to Premier support some time ago and it was never resolved. The issue became, apparently, a mysterious, "we can't reproduce it" "only happens on your machine" "send us your project" etc etc...

Yet it turns out that this "overwriting a R/O .icproj" is a core, well-known behaviour of the IDE integration that should have had an easy answer, and a quick resolution if the issue had ever been "seen" by a knowledgeable engineer who knew the ins-and-outs of IDE integration.

Hello all,

Thanks for your ideas and suggestions. I've sent those to the development team.

I've got notified that the bug that modifies .icproj when doing batch-build is already fixed in the 9.1.034.I tried with 034 on varies projects (console, atl dll, with special intelc options, with post-build event), and used VSS as well, didn't see the "overwritting the .icproj file attribute" issue when opening the property/rebuild the solution.

So please try the 9.1.034, if it still exist, please let us know. It may not be possible to send us all your source code, but if you can provide the .icproj and the relevent .vcproj, it should help us a lot on fixing the problem more quickly.

Thanks again,


vasci_intel ,

>> The IDE integration should never , ever, overwrite a R/O .icproj.

Do you have the issue number so I can follow up on? Maybe we just missed an important step.




I do not know about issues in Batch build. I am using 9.1.034 and the IDE Integration will overwrite the .ICPROJ file even if it is READ-ONLY when it thinks the .VCPROJ has a later date/time. This is 100% reproducible.

Please review the JPG attached to my preivous post

Premier issue is #409143


Hi Jennifer,

Here are simple steps to reproduce the problem....

- In VS 2005 create a simple C++ project

- Convert to Intel System

- Close Solution

- Right-Click on .icproj file, make it "READ-ONLY"

- Open Solution

- In a TEXT EDITOR open the .vcproj file and make a non-destructive change, and save the .vcproj

- IDE Integration will OVEWRITE THE READ-ONLY .icproj file.



>> It may not be possible to send us all your source code, but if you can provide the .icproj and the relevant .vcproj, it should help us a lot on fixing the problem more quickly.

Please do not take this personally...

In regards to this issue (unauthorized renaming project to R/W), your comments is indicative of your failure to recognize the root cause of the problem. And apparently thus the reason why sending you a project will fail to expose the problem.

Consider this:

Someone sends you a R/O project file (and source files). Next, in the process of downloading orof you copying these files from the download directory to a test directory, the files become R/W. You run your tests... No problem exposed.

For this problem, you firstmust understand the problem (without example) as described. Then it becomes a simple matter for you to conceive of a test case such as:

Make a "Hello world" project. Exit the IDE, Rename theicproj and the relevant .vcproj files with same name but with R/O attributes. Copy these files to a separate folder for reference. Then run the IDE (and/or batch build)and see what happens.

a) Are any ofthe icproj and the relevant .vcproj files now R/W? If so why?

b) If not, does WinDiff show any changes

If the answer is No to both a) and b) then problem fixed.

Exception case:

If during your test compile (either from IDE or batch/command line) something aborts due to R/O on icproj and the relevant .vcproj files, then you must recognize that the fix is:

Change the code to be able to use R/O files. (preferred)
Notify the user which icproj and the relevant .vcproj files need to be R/W

The fix is NOT

Use code to change the files to R/W

Why, might you ask. Because the person in charge of source control needs to know if there is any potential for change in "Frozen" source code including icproj and the relevant .vcproj files. It is not appropriate for Intel, Microsoft, or other vendor to usurp this control function.



Thanks so much for the steps Andrew.

I never tried to change the .vcproj. So this is surely a new case. .icproj shouldn't be changed if the .vcproj has changed because the "/sharevcproj" is set by default. So multiple projects/groups can share theproject that hasbeen converted to IntelC.

I've justduplicated the problem with your steps. will create a tracker to the dev-team shortly.

will post the progress here soon.

Thanks again for all your patience.


I think VSS ( SourceSafe ) exacerbates the problem as the modification dates after a 'get' may be identical or possibly the .vcproj may be later by a second or some delta

I am not saying that automatically keeping the .ICPROJ in sync with the .VCPORJ is such a bad thing, but the process should respect the R/O flag.

Leave a Comment

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