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

ifort: error #10273: Fatal error in C:\PROGRA~2\INTELS~1\COMPIL~3\windows\bin\intel64\fortcom, terminated by 0xc0000417

andrew_4619
Honored Contributor II
1,563 Views

The last couple of days I have been getting a few ifort: error #10273: Fatal error in C:\PROGRA~2\INTELS~1\COMPIL~3\windows\bin\intel64\fortcom, terminated by 0xc0000417.  The pattern is random, the source files will compile OK if I retry.  Maybe this is a symptom of a problem on the PC, e.g. AV/memory etc..... but I don't have problems with anything else on the PC.  It is not a big problem but any thoughts, suggestion?

0 Kudos
11 Replies
jimdempseyatthecove
Honored Contributor III
1,562 Views

https://answers.microsoft.com/en-us/musicandvideo/forum/xboxmusic/msvcr90dll-keeps-indicating-an-application-error/77bc2ea9-0132-4b1e-8fa7-2c229e808d4e

This may be a device driver issue:

After reading other posts and trying to do research, I found that uninstalling Zune and any other media manager programs (iTunes, QuickTime, etc.) except Wondows media player and then reinstalling Zune fixed my problem. I have a feeling that the error
occurs because music files might be managed or co-managed by other media programs, or there might be a conflict with codecs which makes Zune go crazy. Basically only have one type of music/movie/stuff manager program on your computer...Zune! :)

and

Since I installed iTunes in April, Zune has continuously crashed with the 1000 event ID.  After reading this thread this morning, I went into Vista task manager and shut down anything labeled "iTunes" (two processes, iTuneshelper
and iTuneslauncher I believe).  Zune's been stable for hours.  Long term fix will probably be to uninstall iTunes.

There were additional posts elsewhere relating to Performance Counter (registry) issues.

(I had a more complete researched post, but IDZ decided I wasn't logged in anymore and trashed my posting, I wish it wouldn't blind-side us this way as some of these posts take 10's of minutes to compose)

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
1,562 Views

As Jim is suggesting, something on your computer is killing the fortcom process. It may not be the particular software mentioned in the post Jim found. You might want to check the Windows event log to see if anything shows up (though the log is generally full of frightening-looking stuff that is ignorable.)

0 Kudos
andrew_4619
Honored Contributor II
1,562 Views

@Jim, I haven't got any of those apps

@Steve, I checked the event log but could find any instances that looks relevant. 

No worries anyway I will see monitor the situation.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,562 Views

One of the posts indicates different driver installation issues (as Steve indicates not necessarily the driver mentioned in post). Use the Device manager to see if you have any /!\ flagged device drivers, if found, try to repair or remove. And additionally look at the System Even Log for errors posted at/near time of program abort.

I must admit is seems unusual for an unrelated device driver to influence the running of an application. Please keep in mind that device drivers tend to insert themselves into layers of other nested device drivers (often called filters). Example: an AV program inserts filters between the application API and the low level storage system (possibly at multiple levels in the driver stack), graphics accelerator, keyboard filter, ...

I remember an issue about 20 years ago where certain mouse movement over a console window caused an application to crash. The application didn't use a mouse!!! This anecdote is not to say your issue is the mouse driver, but rather to say the problem may (initially) appear totally unrelated.

Jim Dempsey

0 Kudos
andrew_4619
Honored Contributor II
1,562 Views

Over a period of a few days this has escalated from an irritation to a major problem as the frequency of failure became such that a full build look several attempts.

Disabling all non MS Services via system configuration and disabling all start up programs in task manager "solved" the problem and from there via selective reintroductions and reboots I have isolated the problem as being Onedrive. The entire tree for the solution is on Onedrive and is this being permanently syncronised. As a quick workaround I created a syncronisation fault condition such that all the files in the local "debug" folder are in a sync error state so they can't be syncronised (removing the debug folder from sync just makes onedrive delete it locally which is no good).   Debug builds now work 100% OK.  

As to the root cause the 0xc0000417. error is generated in the C run-time when a parameter being used does not have a valid value. I am guessing the compiler is accessing  files and there is an access conflict. That may indicate be a 'flaw'  in the compiler? Maybe some additional checks / mutex / blah might prevent this problem? 

The fact that it has become a problems suggest that either Onedrive or the compiler has changed as it has worked OK for quite a long time..... 

Anyway I thought  I would add this comments to update the thread.

 

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,562 Views

>>either Onedrive or the compiler has changed as it has worked OK for quite a long time..... 

See if Onedrive has a tuning feature for the frequency of synchronization. A(n auto) program update may have changed the frequency that Onedrive synchronizes files.

Good detective work on isolating the issue and coming up with a work around. I wonder if your first post included "using Onedrive..." would have solicited a good reply.

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
1,562 Views

The compiler can't do anything here - all it knows is that a file access failed after it had opened the file, and the reason code Windows provides is "unknown software exception".

0 Kudos
DavidWhite
Valued Contributor II
1,562 Views

If OneDrive continues to be an issue, you may be interested in SyncBack.

I have used SyncBack for many years to back up my source code on a periodic basis.  It is fairly cheap, is comprehensive and robust.

Now that we have moved to OneDrive, my development folders are not contained within OneDrive, but independently.  I then have a scheduled SyncBack  process to back them up to the OneDrive synchronised folder, e.g. every 2 or 4 hours.

This has the advantage that if I am repeatedly making changes to the source code while debugging, OneDrive does not see every change, and so this reduces the amount of external traffic (esp. useful when I am on VPN).

David

0 Kudos
andrew_4619
Honored Contributor II
1,562 Views

Thanks for the suggestions David but it is not a backup as I work on different machines at different times (switching often more than once per day) and I have the same content available in all places. I am looking at the project setting to see if the output folders can be moved to a non-synced location.

It is also a possibility to flip  onedrive online/offline but I dont like that idea as I will get caught out by forgetting.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,562 Views

Can you host the file on NFS?

Can you host the development on a Terminal Server (or if you are the only one doing this use Remote Desktop or VNC)?

Jim Dempsey

0 Kudos
andrew_4619
Honored Contributor II
1,562 Views

Update: This problem has gone away due to onedrive updates I believe. Now onedrive does not seem to lock files (and cause a compiler error) instead onedrive throws an error for that file if the compiler starts to work in it whilst trying to sync it. This is a transient error that causes no problem as the file gets synced  at some later time.

0 Kudos
Reply