Prefetch Abort when calling Directory.GetFiles()

In order to track down crashes that happen occasionally when our .NET application starts up, we built a fixture that powers our device on, waits for the application to start, checks its health, and shuts down, over and over.

We have seen a variety of things that cause Data Abort and Prefetch Abort exceptions, which cannot be caught from .NET code and crash the system.

Toradex Support helped identify one of the issues, and we are going to use a different RAM timing.

One of the last things that we see, which we see once out of 500-600 startups, is a prefetch abort when calling making this call:
string patientPlanFileNames = Directory.GetFiles("\FlashDisk\foo\");

That directory always exists.

Any ideas what might be causing this?


Is your application stored on \Flashdisk or you are using a custom OS image that includes the .NET runtime and your own application?
Can you post the exact information you get about the crash on screen and/or on the serial console?

Our application is stored on Flashdisk.

Here is an example of the exception, captured on the serial debug port.

Exception 'Prefetch Abort' (0x3): Thread-Id=04d700c2(pth=a28c9a28), Proc-Id=04500036(pprc=a28a0230) 'R2Derm.C2.App.exe', VM-active=04500036(pprc=a28a0230) 'R2Derm.C2.App.exe'
PC=003f8000(???+0x003f8000) RA=003f6df8(???+0x003f6df8) SP=0318faa4, BVA=003f8000

Exception 'Raised Exception' (0xc0000028): Thread-Id=04d700c2(pth=a28c9a28), Proc-Id=04500036(pprc=a28a0230) 'R2Derm.C2.App.exe', VM-active=04500036(pprc=a28a0230) 'R2Derm.C2.App.exe'
PC=4003fb5b(coredll.dll+0x0002fb5b) RA=80068a1f(kernel.dll+0x00006a1f) SP=0318f688, BVA=00000000

It very consistenty happens after calling the .NET method Directory.GetFiles(). I don’t always see the second “Raised Exception”, but often do, right after the prefetch abort.

Thanks for the additional information. Unfortunately we can not help you further based on that.

We tried to loop 10’000 times the GetFiles() function on a folder with arround 20 files. It worked all fine. Currently we are running the same test with rebooting the device. Let’s see this helps.

Are your running in a multi threaded environment? Could the issue may be happen in a other thread?

Could you once add some more debug output to your application and write it to the Debug output. Add some statements that you know where you already past and what was the last function called, this may helps to better understand what is executed after each other and which was the function triggering this issue.

I prefer not to put the full code here on a public forum, but i have debug lines at every line of code in this neighborhood…before and after the call to Directory.GetFiles(). It always starts there at GetFiles(). Sometimes the lines of exception output are interspersed with a few line of my debugging. Sometimes, the application crashes quickly enough that my debugging stopps afre the Prefretch Abort section.

I’ll start trying to write code to loop through it within a process.

I get you right, the application crashes after the abort right?

We have been running a small application in C# in a loop, the application did not crash so far, at least the Apalis module was rebooting over and over. We used the update tool to reset the device.

Here is the code snipped:

static void Main(string[] args)
            string[] patientPlanFileNames;
            patientPlanFileNames = Directory.GetFiles(@"\FlashDisk\foo\");
            Console.WriteLine("Found {0} items.", patientPlanFileNames.Length);
            Console.WriteLine("Rebooting now");
            ProcessStartInfo startInfo = new ProcessStartInfo();
            startInfo.FileName = "update.exe";
            startInfo.Arguments = "/r";

If you want to share some code with us, you can upload it to and share the link you get over the support email address (

Interestingly, I swapped machines (and Apalises) that I was using for the fixture. Now, I never get the application crash on the Directory.GetFiles() call. Instead, I get it extremely early in my application main method. FWIW, the new machine is not setup with 533 RAM timing.

@dmcreynolds: If you see this issue only on one single moduel, also you have applied the same settings, it could also be a hardware issue. May be some RAM pins are loosely connected and with higher temperatures there is a communication issue. If it is really only that single module, that you see these issues, please return this module to us and we can have a closer look on it. You get the instruction how to open up an RMA request here.