1

I get an exit error code 0xc0000417 (which translates to STATUS_INVALID_CRUNTIME_PARAMETER) in my executable (mixed Fortran/C) and try to find out what's causing it. It seems to occur when trying to write to a file which I infer because the file is created but there's nothing in it. Yet I have the suspicion that's not the /real/ cause. When I disable writing of that file, which is done from C code, it crashes when writing a different file, this time from Fortran code.

The unfortunate thing is: this only happens after the program (a CPU heavy calculation) has finished after having run for ~2-3 days. When I tried to shorten the calculation time by various means to facilitate debugging, the problem did not occur anymore. It almost seemed like the long runtime was crucial for triggering the problem.

I tried running it in Visual Studio 2015 but VS does not break/stop (like it would if e.g. a segfault had happened) despite having turned on breaking at all the C++ Exceptions, like was suggested in some other thread and all Common Language Runtime Exceptions.

What I would like VS to do is to either break whenever that error code is 'produced' and examine the values of variables or at least get a stack trace.

I searched intensively but I could not find a satisfactory solution to my problem. In essence, my question is similar to how to debug "Invalid parameter passed to C runtime function"? but the problem does not occur with the linux version of my program, so I'm looking for directions on how to debug it on Windows, either with Visual Studio or some other tool.

Edit: Sadly, I was not able to find any convenient means of breaking automatically when the error occurs. So I went with the manual way of setting a breakpoint (in VS) near the supposed crash and step through the code. It turned out that I got a NULL pointer from fopen:

myfile = fopen("somedir\\somefile.xml");

despite the file being created. But when trying to write to that file (via the NULL handle!), a segfault occurred. Strangely, it seems I only get a NULL pointer from fopen when the process has a long lifetime. But that's offtopic for that question.

Edit 2: Checking the global errno variable gave error code 22 which again translates to an invalid argument. However, the argument to fopen is not invalid as I verified with the debugger and the fact that the file is actually created correctly (with 0 bytes length). Now I think that that that error code 22 is simply misleading because when I check (via a watch in VS) $err, hr I get:

0x000005aa ERROR_NO_SYSTEM_RESOURCES : Insufficient system resources exist to complete the requested service.

Just like mentioned here, I have plenty of HD space (1.4 GB), plenty of free RAM (3.2 GB), and I fear it is something not directly caused by my program but something due to broken Windows design of file handling (it does not happen under Linux).

Edit 3: OK, it seems it is not Windows itself that's the culprit but rather the Intel Fortran compiler I'm using. Every time I'm doing formatted write statements in my program, a Mutant (Windows speak for mutex) handle is leaked. Using WinDbg and !htrace -enable, then running a bit further, break and issue !htrace -diff gives loads of these backtraces:

0x00000000777ca25a: ntdll!NtCreateMutant+0x000000000000000a
0x000007fefd54a1b7: KERNELBASE!CreateMutexExW+0x0000000000000057
0x000007fefd551d60: KERNELBASE!CreateMutexExA+0x0000000000000050
0x000007fedfab24db: libifcoremd!for_lge_ssll+0x0000000000001dcb
0x000007fedfb03ed6: libifcoremd!for_write_int_fmt+0x0000000000000056
0x000000014085aa21: myprog!MY_ROUTINE+0x0000000000000121

During the program runtime these mutant handles seem to accumulate until they exhaust all handle resources (16711680 handles) so that there's nothing left for file handles.

Edit 4: It's a bug in the intel fortran runtime libraries that has been fixed with a later version (see here). Using the patched version of libifcoremd.dll fixes the problem, i.e. the handle count does not increase anymore during formatted writes.

lineinthesand
  • 237
  • 1
  • 5
  • 15
  • _[This is related...](https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/04f1c082-79db-4f41-82fc-3d41b14c8713/regarding-error-quotstatusinvalidcruntimeparameterquot-c0000417?forum=vcgeneral)_. And here is an almost _[identical question/answer.](https://stackoverflow.com/a/38151124/645128)_ – ryyker Mar 13 '19 at 12:01
  • 1
    Possible duplicate of [How do identify STATUS\_INVALID\_CRUNTIME\_PARAMETER exception](https://stackoverflow.com/questions/38135608/how-do-identify-status-invalid-cruntime-parameter-exception) – ryyker Mar 13 '19 at 12:03
  • Regarding _I searched intensively..._ I appreciate that sometimes after what seems like several attempts at finding the right query string for a Google search, the right response just never seems to pop. In this case I used _STATUS_INVALID_CRUNTIME_PARAMETER on Visual Studio_, and the first two links are the two links I commented above. – ryyker Mar 13 '19 at 12:06
  • I had checked all of the articles you linked before posting here but I did not succeed in debugging. The only thing I could do was to set a break point somewhere near that supposed crash. Now, after 3 days I'm finally at the cause: fopen("somedir\\somefile.xml","w") returns a NULL pointer despite the file being created. But that's a different question. – lineinthesand Mar 18 '19 at 08:26
  • Well, if it's something that happens after a while, you may have issues like: fragmented address space (some allocations therefore are destined to fail), leaked memory (with the same outcome), race condition (leading to inconsistent/corrupt state), overflow of some important index/count/pointer, memory corruption. – Alexey Frunze Mar 18 '19 at 09:17
  • I am happy to see you have found some thing that at least is contributing to your mystery. In general, without a [mcve] included as part of your post, it is impossible for anyone to know how to help. This is a good example. If you would have included that section of code originally, somebody would have asked about checking the return value of those functions that have them. – ryyker Mar 18 '19 at 12:00
  • Even if I had been able to include an example (which was not possible since I did not know the location of the error and the purpose of my question was to find a method how to catch the location) the question still remains: why does fopen return a NULL? – lineinthesand Mar 20 '19 at 08:12
  • @AlexeyFrunze: at least I can exclude memory corruption (valgrind and DrMemory agree there's none). If I was to guess, I would say it must be some kind of overflow (depending on the process runtime). But maybe I'll know more later today or tomorrow; I included a strerror(errno) in my code hopefully giving me more information about the fopen error. – lineinthesand Mar 20 '19 at 08:20
  • Btw, what about other resources? Too many open files? Leaked (not closed) handles? Can you check that with e.g. process explorer (I think you could see the number of handles in the process with it)? – Alexey Frunze Mar 21 '19 at 09:18
  • @AlexeyFrunze: Yes, that seems to be it: the intel fortran lib leaks mutant (mutex) handles on each formatted write eventually exhausting all resources during the (long) runtime. – lineinthesand Mar 21 '19 at 16:33
  • I'm making that the answer then. – Alexey Frunze Mar 22 '19 at 04:08

1 Answers1

0

It could be too many open files or leaked (not closed) handles. You can check that with e.g. Process Explorer (I think you could see the number of handles in the process with it).

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • 1
    It turned out it is a known (and fixed) bug in the Intel runtime libraries: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/591225. Using a patched libifcoremd.dll fixes the problem, the handles behave well (o; – lineinthesand Mar 22 '19 at 09:12