Crash Running MFCMAPI Overnight

So – one of my teammates tells me that if he leaves MFCMAPI running overnight, it has usually crashed by the time he comes in the next morning. We got a few dumps, but they were inconclusive since the stacks were completely different every time. Since we didn’t know what was going on, we started paying attention to when and where the problem happened. We noted the following:

  • He usually runs MFCMAPI from a tools share on one of my machines.
  • If he copies MFCMAPI locally and runs it overnight, it never crashes.
  • If he tries running some other tools from the same share, he can cause them to crash overnight as well.
  • Another engineer who overheard us discussing the problem was also able to reproduce it.

Armed with this information, I decided to look at the dumps again. The exception thrown in each was 0xC0000006, STATUS_IN_PAGE_ERROR. Ok – so that’s explains things – maybe some network hiccup causes us to lose the connection to the original executable, then the next time the process needs to load a page of memory it can’t find it?

For a while, I thought this was the end of the investigation – there’s no way MFCMAPI can control network hiccups, right? Then I stumbled across this linker option:


Basically, when this option is set, the OS will copy the whole binary image to a local swap file before running it. We set the “Swap Run From Network” switch on a test build, and he hasn’t been able to reproduce the crash again. If you’re in to manually editing your .vcproj file, this is the equivalent of adding the line


to the “VCLinkerTool” section of your project’s configuration.

The next version of MFCMAPI will have this option enabled for all configurations.

Comments (5)

  1. Lev says:

    Thanks for the tip.  Why would you want to enable it for everyone, though?  Increasing the size of swap file comes at a cost – let your coworkers set the flag locally – it’s open source! 🙂

  2. Stephen Griffin says:

    It’s not something you can control after your process starts, so I don’t see a way I could configure the behavior on the fly. The only way for my coworkers to set the flag themselves is to build the tool themselves, implying that it’s running locally, in which case the switch has no effect (the OS only does this copy when run over the net).

  3. Steve Thresher says:

    We hit the same problem a couple of years ago and had to implement the same fix. I was really hoping for an explanation but it’s nice to know we implemented the correct fix.

  4. Stephen Griffin says:

    The explanation really is what I gave – there was a network hiccup (his machine was especially prone to them) that severed the connection between his machine and mine. The connection can be restored, but the process that was running is now timebombed. The moment it tries to access a page of code that wasn’t already in memory, it will fault. Setting the linker option forces the OS to pull the pages locally first so this hiccup can’t affect it.

  5. The March 2009 Release (build is live: . Note the new URL – the