Compilation failed with application crash

Compilation failed with application crash


I used C++ Composer XE 2011 update 6 with VS2010 on Windows 7 x64 platform. The compilation failed with the crash information "mcpcom.exe has stopped working" with the following details:
Problem signature:
Problem Event Name: APPCRASH
Application Name: mcpcom.exe
Application Version:
Application Timestamp: 4e44b9af
Fault Module Name: StackHash_dd15
Fault Module Version:
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 000000006fff03e8
OS Version: 6.1.7600.
Locale ID: 1033
Additional Information 1: dd15
Additional Information 2: dd152986fe395b5a883659aefed8eb71
Additional Information 3: af43
Additional Information 4: af43a00ee10606b603d5ffb3aac00165

Read our privacy statement online:

If the online privacy statement is not available, please read our privacy statement offline:

The build log is as follows:
1>------ Build started: Project: test, Configuration: Release x64 ------
1> main.c
1> compilation aborted for ..\\src\\main.c (code -1073741819)
1>C:\\Program Files (x86)\\MSBuild\\Microsoft.Cpp\\v4.0\\Platforms\\x64\\PlatformToolsets\\Intel C++ Compiler XE 12.1\\Microsoft.Cpp.x64.Intel C++ Compiler XE 12.1.targets(211,5): error MSB6006: "icl.exe" exited with code -1073741819.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

However, the compilation on Windows XP 32bit platform was successful.

Anyone have ideas on solving this problem?


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

It would be nice if you could share the testcase.

Yeah, with compiler crashes/internal errors like this one, we at support really need a reproducible test case to diagnose the problem. Sometimes an assertion or code is emitted that can be used to help identify the problem, but a lot of times errors that can occur for very different reasons will emit similar codes, so it's not something I would rely on. Fortunately, it's usually pretty simple to provide a test case for these issues assuming there are no IP concerns - just preprocess the source file with the problem by adding the -P compiler option (this will generatea .i file), then send us the .i file along with the compiler options used when you get the crash/error. You may want to compile the .i file (you can use -TC or -TP to compile as C or as C++ respectively) just as a sanity check to make sure it still reproduces the issue.

This is just a simple "Hello, World!" C file. I recompiled the main.c file with the compiler options as follows:

/Zi /nologo /W3 /O2 /Oi /Qipo /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /P /EHsc /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fp"x64\Release\test.pch" /Fa"x64\Release" /Fo"x64\Release" /Fd"x64\Release\vc100.pdb" /TC

I just added the /P and /TC to the default compiler options and the generated .i file was attached.


Downloadapplication/octet-stream main.i51.99 KB

I was unable to duplicate your compilation error with the compiler options and previously attached main.i file. Can you please attach your entire project?

I recompiled the project with different settings. The Debug Win32 and Release Win32 were OK, while the Debug x64 and Release x64 failed with the same error as mentioned previously.

The entire project was attached.


Downloadapplication/zip test.zip86.43 MB

This is weird...

Your solution seems to be broken somehow because I cannot compile it using Intel Composer 2011 Update 7 as well.

Compilation with MSVC (both debug and release x64) work fine. If I recreate the solution then everything works fine.

The weird part is that there is virtually no difference between your project .vcxproj and .sln files and mine (apart from project GUID assigned)!

I can only suggest one thing, and that is to create a new solution to see if the problem goes away.

I would also like to note that when you create separate folder for a solution (so you can have multiple projects inside) it is not very logical to place the source code in the solution folder itself.

Hello everybody,

Look there is an Access Violation exception in the log:

Exception Code: c0000005
Exception Offset: 000000006fff03e8

Also, there is an exit code -1073741819, and if you convert it from Radix10 to Radix16 you will get:


Personally, I would report it asa bug in the icl.exe.

If some software subsystem in the compiler writes some datato a wrong memory address how could you solve it? There is only one way to solve it, that is,at the source codes level by Intel developers.

Best regards,


Bugs in the code are sometimes not isolated to a single component -- they are a consequence of interactions between various components (in this case icl.exe and the VS2010 build system).

C000005 is a generic error code that indicates a stray pointer has been used to access (it can also be read, not only write) memory. But that bad pointer can be a result of another component and even a particular OS function which behaves differently in Windows 7 and in Windows XP for some reason known only to Microsoft developers.

He should most certainly file a bug with Premier support, but just reporting it without trying to create an isolated and reproducible test case will not allow Intel developers to fix it.

Hi Igor,

I recreated the solution and put the source code main.c outside the solution folder as you recommended. Unfortunately, the compilation still failed and the problem remained the same. Did the problem related with some broken components of x64 platform?

I am unable toduplicate your compilation failure issue. Can youattach the projectlog file with environment variables? You can enable the environment variables through Tools >> Options >> Projects and Solutions >> VC++ Project Settings. Change the option for the "Show Environment in Log" to Yes thenrebuild your project. The test.log file should be located under your \test\test\x64\Release file directory.


When the failure happens does it showJust-In-Time Debugger window? Like:

What I wanted to suggest you need to attach the MS VS Debugger to an application, icl.exe or mcpcom.exe, somehow during the compilation process!

If you managed to do this you will be able to see some codes in a Dissasembly Window when an Access Violation happens.

Also, did you have a chance to look at a Windows' 'Minidump' folder? It is usually located in:


If you find some dumps related to your problem it is a good idea to forward them to Intel's developers.

Best regards,


(211,5): error MSB6006: "icl.exe" exited...

Did you have a chance to search forerror MSB6006 on the Web? You will find lots of interesting stories!

Ilooked at some of them and I have a concern that it could beMicrosoft's problem rather than Intel'sbecause two Intel's developers couldn't reproduce the crash...


some time ago Microsoft has released several Service Packs ( SPs )for MS Visual Studios ( 2005, 2008 and 2010 ) and lots of updatesfor different versions of .NET. Would you be able to check if your computerhas all Microsoft'supdates?

It is really hard to believe that you have that problem but who knows maybe that bug ( if this is a really Microsoft's bug )isalready fixed in one of these SPs orupdates.

Best regards,

Hi Elroy,

The log file has been attached.


Downloadapplication/octet-stream test.log3.68 KB

Hi Sergey,

Yes, it showed the Just-In-Time Debugger window. The Disassembly information was attached.

I checked the Minidump folder and there was no dump files in it.

Hi Lee,

From your log it looks like compiler is again getting a relative path for the C file (..\..\main.c). It does not look like the source file is in the right place in the hierarchy.

What I suggested was:

TEST <- solution dir
+ TEST <- project dir
+ SRC <- source dir for project
+ main.c

The path compiler is getting in the command line should be something like .\test\test\src\main.c in that case.

Can you please also try creating a new project without creating a separate solution folder (i.e. leave the option unchecked) and keep the source in the main folder just like it is usually done? I would like to eliminate folder hierarchy as a possible cause.

Hi Lee,

So, here is some summary:

1. The crash happens in mcpcom.exe application and it belongs to Intel, right?

2. Intel's software developers claimed that they couldn't reproduce the problem;

3. I just found that a similar mcpcom problem happened in 2005 for a Linux version of Intel's compiler:

Please follow the link because there are a couple of useful comments;

4.When the crash happens:
- attach a VS Debugger to aworking copy of VS;
- then open a Disassembly window and look for some function names a couple of code-pages up
and down( PgUp &PgDn );
- since mcpcom.exe is a Release version you won't see to much, but you could find some names or
labelsand it could help to understand the problem;

5. Also, regarding a comment andconcern about a relative path to 'main.c' file. Try to rename 'main.c' to 'main.1.c'in Windows Explorer ( not in VS! )but keep the original name in VS and see what happens. If VS & ICC & your projectare properly configured your error message could look like:

Cannot open source file: '.\main.c': No such file or directory

and ifit still craches follow the instruction #4...

6. Try to change 'Output verbosity' setting:

Good luck!

Look what I found on

I finally could solve the problem, so I just would like to share this experience: looking at the logs on my system, I have seen a kernel message telling it had killed mcpcom, due to a huge memory consumption:

Feb 9 15:15:37 foo kernel: Out of Memory: Killed process 15204 (mcpcom).

So I simply added some extra swap, and everything went fine. Running some monitoring tool in parallel, I could see the compiler was using about 400 MB of memory.

PS: I would also check log records ina Windows Event Viewer.

Hi Igor,

As you recommended, I created a new project test2 without separate solution folder, and put the main.c in the src folder under the main folder test2. The problem remained unsolved. I think that the problem might not be related to the folder hierarchy.

The whole project test2 and build log file test2.log were attached.


Downloadapplication/octet-stream test2.log3.71 KB
Downloadapplication/zip test2.zip1.02 MB

Hi Everybody,


1. Did you try to increasesize of your Virtual Memory? ( for example, twice )
2.Did you do Windows Updates verfication?
3.Could you look at what is going on in aTask Manager when the crash happens?
4.Could you look at Events Log just right after the crash?
5.Do you have a DrWatson.exe application in a Windows folder? If Yes, start it, reproduce the crash, follow steps 3 and 4 please.
6. Do you have any Anti-Virus software installed. If Yes, disable it and try reproduce the crash, follow steps 3 and 4, again.

Some screenshoots from the Task Managerwould be very useful.

Igor, what do you think about the last resort - Reinstall MS Visual Studio?

Best regards,

PS: Lee, thanks for updated Test projects. I've downloaded already and will look tonight.

I think I know now what the problem might be, but unfortunately not how to properly solve it.

Please try these steps to confirm:

1. Launch Parallel Studio 2011->Command prompt->Intel 64 Visual Studio 2010 mode from the Start Menu
2. In the command prompt window type:

devenv /UseEnv

This command will launch Visual Studio instance which will inherit environment variables from the command prompt.

3. Load your solution and build it in x64 mode.

If it succeeds then the problem is with the incorrect or missing PATH setting for cross-compile binaries (C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64 and/or C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE are not in path).

If you still have problems, then there are two separate issues at play here.


What aboutverification of the Visual Studio's global settings, etc:

'Tools' -> 'Projects and Solutions' ->'VC++ Directories'

Lee, I had a chance to look at your Test2 project settings and I have Not found anything suspicious.

So, I've asked myself what I would do in the situation like this? My answer is:

I would try to re-install thesoftware.

Hi Sergey,

As you recommended, I tried several times, and doubling the virtual memory did not helped. All the updates for VS2010 has been installed. There was no Dr. Watson application and Anti-Virus software installed in the system. When the crash happens, there was no obviously change in the Task Manager, and the Events Log reported an application error of mcpcom.exe as follows:

Hi Igor,

I updated the compiler to update 7 just now and the problem remained. According to your direction, I launched the command prompt. There was a error message 'ERROR: Cannot determine the location of the VS Common Tools folder.' and it failed to recognize the command 'devenv /UseEnv'.

So, I think that there is something missing in the PATH settings. Do you have some suggestions about fixing this issue?

PS. I installed the VS2010 under the 'E:\ProgramW7\Microsoft Visual Studio 10.0' other than the default 'C:\Program Files (x86)\Microsoft Visual Studio 10.0'.

can you try to build from a command window?

Start > All program > Intel Parallel Composer XE > Command Prompt > Parallel Studio XE for Intel C++.... > IA32 VS2010 mode

Then try:
icl /O2 /EHsc /MD main.cpp


Hi Sergey,

I checked the VS settings shown by you. It told that editing this option in Tools > Options has been deprecated and this option was added by default to all project.

Also, I checked the Project Property Pages, and found the settings.

It seems that the settings are OK.

Hi Jennifer,

The compilation in the command prompt of IA32 VS2010 mode failed due to the similar reasons as I mentioned in the post #23. However, the compilation in the VS2010 IDE under the Win32 platform was OK.


Can you please:

1. Open a command prompt window
2. Type:

set vs

3. Tell me whether you get



b)Environment variable vs not defined

If you get b), can you please:

1. Right-click Computer->Properties
2. Click on Advanced System Settings
3. Click on Environment Variables...
4. Create new environment variable under System Variables as follows:

Variable Name: VS100COMNTOOLS
Variable Value: E:\ProgramW7\Microsoft Visual Studio 10.0\Common7\Tools\

Afterwards, restart your computer and then try building a project.

Hi Everybody,

...installed the VS2010 under the 'E:\ProgramW7\Microsoft Visual Studio 10.0' other than the default 'C:\Program Files (x86)\Microsoft Visual Studio 10.0'...

Lee, I have a question about E drive. Is that a network drive?

In my previous post I suggested a last resort: Re-install the software ( to default location with un-install first).

Of course, it doesn't meanthat the problem will be resolved, but from my point of view something more crucial, like re-install, has to be done. I understand that it could be a time consuming procedure...

Also, just came to my mind. As far as I remember an installer in aVisual Studio allows to do Repair or something like this. Could you look at this?

Best regards,


The command 'set vs' get the result a) as follows:

C:\Users\lee>set vs
VS100COMNTOOLS=e:\ProgramW7\Microsoft Visual Studio 10.0\Common7\Tools\
VS90COMNTOOLS=E:\ProgramW7\Microsoft Visual Studio 9.0\Common7\Tools\

So, the environment variables looks like to be correct.

Two more questions:

1. Do you also have Visual Studio 2008 installed and do you use it?
2. Can you please provide the output of set PATH command?

Yes, I installed and used the VS2008 for my work after the problem (mcpcom.exe application crash under VS2010) happened.

The set PATH command gave the information as follows:

C:\Users\lee>set PATH
PATH=E:\ProgramW7\Intel\Composer XE 2011 SP1\redist\ia32\tbb\vc10;E:\ProgramW7\I
ntel\Composer XE 2011 SP1\redist\intel64\tbb\vc10;E:\ProgramW7\Intel\Composer XE
2011 SP1\redist\intel64\ipp;E:\ProgramW7\Intel\Composer XE 2011 SP1\redist\ia32
\ipp;E:\ProgramW7\Intel\Composer XE 2011 SP1\redist\intel64\mkl;E:\ProgramW7\Int
el\Composer XE 2011 SP1\redist\ia32\mkl;C:\Program Files (x86)\Common Files\Inte
l\Shared Libraries\redist\intel64\compiler;C:\Program Files (x86)\Common Files\I
ntel\Shared Libraries\redist\ia32\compiler

Hi Sergey,

E drive is just a partition in the local drive.

I will try to repair the installation of VS2010.

There is an error in the cmd window. From your posting on the env var "path", the env var "path" is not good.

It should contain the windows directories and some VS directories. See below for example. Do not copy/paste, need to update according to your env:


C:\Program Files\ThinkPad\Bluetooth Software\;C:\Program Files\ThinkPad\Bluetooth Software\syswow64;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DT

S\Binn\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\

The directories to Intel compiler, just need to keep the latest version, the dir to the older versions can be removed.



Please try moving the following:

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redis\intel64\compiler;
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler;

To the beginning of your PATH. Log off and back on after changing PATH, then try to recompile.

If that doesn't work, then I am out of ideas apart from full and clean reinstallation of Intel Compiler.



Why does Intel Parallel Studio 2011 SP1 Update 7 have irml.dll and irml_debug.dll in two places and with two different versions?

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler\irml
irml.dll version 4.0.2011.0809
irml_debug.dll version 4.0.2011.0809

C:\Program Files (x86)\Intel\Parallel Studio 2011\Composer SP1\redist\ia32\tbb\vc10\irml
irml.dll version 4.0.2011.1003
irml_debug.dll version 4.0.2011.1003

Isn't that something that should be avoided especially if both folders are listed in PATH?

Another question for you is why are the files in:
C:\Program Files (x86)\Intel\Parallel Studio 2011\Composer SP1\redist\ia32\compiler

Duplicated at:
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler

Why not just use the first copy (which is on the same path as IPP/TBB/MKL runtime) instead of installing a copy of the compiler runtime into Common Files?

Hi Lee,

I'm really sorry to hear that you still have a problem.So, Good Luck with Repair!

Best regards,


Changing the order of PATH did not helped. So, I will try to clean and reinstall the Intel Compiler.

Hi everybody,

I repaired the VS2010 and cleaned and reinstalled the Intel Compiler. Unfortunately, the problem remained.

I think that the problem might be due to some unknown bugs within the VS2010. Maybe the solution is waiting for the new updates and fixes for VS2010.

Thanks everybody for your help!

Best regards,

Did you also repair your PATH as Jennifer suggested?

Your PATH is missing the following Windows 7 default entries:


They should be at the beginning, before all other items.

After repairing the PATH (and assuming that doesn't help), at this point I would try reinstalling VS2010 and, if you have a separate installation of Windows SDK, that too. I would install all that (including Intel Compiler) to a default location just to be sure.

My opinion is that there is something broken in your installation.

Yes. I repaired the PATH as you and Jennifer suggested, and it did not help.

I have no idea that why this problem happened to VS2010 while VS2008 works well with Intel Compiler. Both the VS2010 and VS2008 were installed under E:\ProgramW7 as well as the Intel Compiler. Maybe some component within VS2010 supported Intel Compiler not so well.

Hi Lee,

Did you have a chance to contact Microsoft Support regarding an error MSB6006? If your product is fully licencedyou shouldn't have any problems.

If you decide to follow that path I recommend you to create a "master list" of all recomendations/attempts based on our posts. Microsoft's Support representative could ask you a lot of questions in order to understand your problem.

Best regards,


I hacked a small diagnostic tool (source code attached). Please compile it using MSVC (console application), and replace your real ICL.EXE with the tool.

Afterwards you can try compiling the test2 project, and then attaching the resulting files that will be saved to your C: drive (ICL_ARG.TXT, ICL_CWD.TXT, and ICL_ENV.TXT).

Hopefully that will help us narrow down the problem.


I compiled the icl.c with VS2008 and replaced the real icl.exe with the generated icl.exe under folder 'E:\ProgramW7\Intel\Composer XE 2011 SP1\bin\intel64'. The resulting files were attached as follows.


MSBuild is passing a response file to compiler instead of command line.

I have changed the code. Please recompile and run again. This time you will get ICL_RSP.TXT instead of ICL_ARG.TXT.


Downloadtext/x-csrc icl.c2.27 KB


The new resulting files were attached as follows.


Downloadtext/plain ICL_CWD.TXT114 bytes
Downloadtext/plain ICL_ENV.TXT4.2 KB
Downloadtext/plain ICL_RSP.TXT530 bytes


From the ICL_RSP.TXT you can see that for some reason, the compiler does not get the correct path to the linker:


If I understand correctly, $(VCInstallDir) should be substituted with real path. This is not immediately noticeable since compiler is being invoked with /c (compile only). However, if you remove /c it then complains:

icl: error #10037: could not find '$(VCInstallDir)\bin\x86_amd64'

I am not sure how to resolve that and whether it will help -- perhaps you can manually substitute it with fully qualified path in Visual Studio settings.

Also, my version of compiler complains about /Qftz-:

icl: command line remark #10148: option '/Qftz-' not supported

Moreover, I noticed that you have /Qipo enabled. It is known to cause problems in some cases and for smaller projects it may not give any performance benefits so it might be a good thing to try disabling it just to be sure.

Furthermore, I have noticed some environment variables which are unknown to me (Google shows nothing even remotely similar):

TRACKER_INTERMEDIATE=C:\Users\lee\Documents\Visual Studio 2010\Projects\test2\x64\Release

I see that it is mentioning icl so it might be worth looking into it -- perhaps you have insstalled an addon for VS2010 (or you have enabled some feature in VS2010?) which is causing Intel Compiler to crash?

Finally, I would like you to try compiling from the 64-bit Intel Compiler command prompt again -- since you have repaired your VS2010 installation it should work now. Please open 64-bit ICL command prompt, CD to your test2 solution folder and use the following command line:

icl /c /Qvc10 /Qlocation,link,"$(VCInstallDir)\bin\x86_amd64" /Zi /nologo /W3 /O2 /Oi /Qipo /Qftz- /D WIN32 /D NDEBUG /D _CONSOLE /D _UNICODE /D UNICODE /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fo"x64\Release\" /Fd"x64\Release\vc100.pdb" /TC src\main.c

If that doesn't crash, try removing option /c to see if it crashes because of unexpanded $(VCInstallDir).

If you still have the same error when you open command prompt ("ERROR: Cannot determine the location of the VS Common Tools folder"), then your VS2010 installation is broken. Please check for the presence of one of the following registry keys:


Because that is where the vsvars32.bat and other VS2010 batch files look for the path. On my system, I found it in the underlined key.


As you recommended, I tried several cases from the command prompt. When I openned the Intel Compiler command prompt for Intel 64 Visual Studio 2010 mode, there is no error any more:
Intel Inspector XE 2011 (build 189290)
Intel VTune Amplifier XE 2011 (build 186533)
Intel Parallel Studio XE 2011 SP1
Copyright (C) 1985-2011 Intel Corporation. All rights reserved.
Intel Composer XE 2011 Update 7 (package 258)
Setting environment for using Microsoft Visual Studio 2010 x64 tools.

E:\ProgramW7\Intel\Composer XE 2011 SP1>

I also checked the registry keys as you listed to be sure, and found that the 2nd entry as you underlined is OK while the other three entries don't exist. This is the same as you.
Windows Registry Editor Version 5.00

"9.0"="E:\\ProgramW7\\Microsoft Visual Studio 9.0\"
"10.0"="E:\\ProgramW7\\Microsoft Visual Studio 10.0\"

So, the VS2010 installation should be OK.

From the command prompt, I compiled the test2 with the command line shown by you, and the main.obj file was generated in "x64\Release" without any crash.
C:\Users\lee\Documents\Visual Studio 2010\Projects\test2>icl /c /Qvc10 /Qlocatio
n,link,"$(VCInstallDir)\bin\x86_amd64" /Zi /nologo /W3 /O2 /Oi /Qipo /Qftz- /D W
/Zc:wchar_t /Zc:forScope /Fo"x64\Release\" /Fd"x64\Release\vc100.pdb" /TC src\m

By removing the /c option, it gave the ipo remarks and complained the location of '$(VCInstallDir)\bin\x86_amd64', and the main.obj was also generated without any crash.
C:\Users\lee\Documents\Visual Studio 2010\Projects\test2>icl /Qvc10 /Qlocation,l
ink,"$(VCInstallDir)\bin\x86_amd64" /Zi /nologo /W3 /O2 /Oi /Qipo /Qftz- /D WIN3
2 /D NDEBUG /D _CONSOLE /D _UNICODE /D UNICODE /EHsc /MD /GS /Gy /fp:precise /Zc
:wchar_t /Zc:forScope /Fo"x64\Release\" /Fd"x64\Release\vc100.pdb" /TC src\main
ipo: remark #11001: performing single-file optimizations
ipo: remark #11006: generating object file x64\Release\ipo_out.obj
icl: error #10037: could not find '$(VCInstallDir)\bin\x86_amd64'

Moreover, by removing the /Qipo option, it didn't give the remark about ipo any more, and the vc100.pdb was generated besides the main.obj.

I founded the $(VCInstallDir) in the VS2010 settings that $(VCInstallDir)=E:\ProgramW7\Microsoft Visual Studio 10.0\VC.

From the command prompt, I manually substituted the $(VCInstallDir) with the full real path "E:\ProgramW7\Microsoft Visual Studio 10.0\VC" and recompiled the program with the same options as before:

icl /Qvc10 /Qlocation,link,"E:\ProgramW7\Microsoft Visual Studio 10.0\VC\bin\x86_amd64" /Zi /nologo /W3 /O2 /Oi /Qftz- /D WIN32 /D NDEBUG /D _CONSOLE /D _UNICODE /D UNICODE /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fo"x64\Release\" /Fd"x64\Release\vc100.pdb" /TC src\main.c

The compiler succeeded in generating the main.exe executable without any error. The compilation and linking were also successful with the /Qipo option enabled, and it just reported the ipo remarks as before.

So, building the program from the command prompt looks like successful.


What I meant is to replace the $(VCInstallDir) in the VS2010 Intel Compiler settings with fully qualified path and try building from the IDE.

That option is located under Tools->Options->Intel C++ Composer XE 2011->Compilers->Default Options.

Can you please try that as well and report back?

Also, you didn't comment on those TRACKER_<...> environment variables?


I replace the $(VCInstallDir) in the VS2010 Intel Compiler settings with the full path "E:\ProgramW7\Microsoft Visual Studio 10.0\VC". Unfortunately, the building from IDE failed for the same reason (mcpcom.exe crash) as before.

As for the TRACKER_<...> environment variables, I have no idea for what purpose they are set. I didn't install other add-on for VS2010 other than the Intel Compiler Suite, and just found the tracker.exe in the folder "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools" and its x64 folder. Maybe the tracker is a component of VS2010 for tracing bugs or something else.

Regarding TRACKER, you are right, that is the executable which contains environment variables. It isBuild (MSBuild) File Tracker which is used to track the build process and generate those .tlog files which show read/write access to various files during compile time.

Back to square one then...

1. Is there any reason you did not install Windows 7 SP1?

2. Did you install VS2010 SP1?


Leave a Comment

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