Visual Studio 2010 binary corruption issue on exFAT drives

[Created 17/Apr/2010: First version of this page.]

Connect bug report: I have submitted this as Connect bug ID 552011. You can track the bug, vote for it to be fixed or confirm that you can reproduce it there.



There appears to be a bug in Visual Studio 2010 RTM and/or the exFAT filesystem (under Windows 7 RTM x64, at least) which causes binaries built by VS2010 to be silently and frequently corrupted if the project is built on an exFAT drive.

Projects on exFAT drives build without warnings or errors and yet (more often than not) turn out to be corrupt when you attempt to run them. Affected DLLs simply won't load while EXEs fail to run and instead show a message box saying:

"The application was unable to start correctly (0xc000000d). Click OK to close the application."

Screenshot of application failure.

Sometimes you get lucky and the program runs but if you close it, Rebuild All and try it again, chances are it (or one of its DLLs) will fail. It should only take a handful of tries to reproduce the problem. If you are doing this with a big, multi-component project then you can safely bet that some of your components will be corrupted after most builds.

I am not certain that the project must be on exFAT to trigger this but that does seem to be the case so far. Equally, I don't know if something VS2010 does is triggering a bug in exFAT or vice versa.

A very simple project is provided (see below) with which you can reproduce the problem. If you copy it to an exFAT HDD and then rebuild it and try to run it a few times, you should soon see that exe and/or DLL produced are corrupted and display an error message when you try to run them.

Below I detail the steps to create the example project as well as how to create an exFAT HDD.

The example project isn't special; it's just a simple example made to demonstrate the problem. The problem was first noticed while converting a real project to VS2010. My source drive happens to be exFAT and I noticed my binaries would randomly work or not work each time I did a build. During a day's investigation, ruling out 3rd party tools & drivers and anything peculiar to the original project, I made several very simple projects which still reproduced the problem; the provided project is the simplest one.

I'm looking forward to using VS2010's new C++ and editor features but I'm going to stick with VS2008 for a bit longer until I can be confident about the binaries VS2010 outputs. If the issue is fixed, or an explanation is given that shows it definitely only affects exFAT drives (allowing me to format my drive as something else and use VS2010 with confidence), then I'll definitely start using it again.

(Thanks to Jonathan Potter for suggesting I check the filesystem and probably saving me several hours of investigation. I'd forgotten all about choosing exFAT for that drive so long ago. :-))

Extra details:

  • Visual Studio 2010 Professional RTM was used. (Visual Studio 2008 does not trigger the problem.)

  • C++ is used. (I don't know if this affects other languages.)

  • Windows 7 RTM x64 was used on two real machines and on a third VMware 7.0.1 virtual machine. (I have not tried on x86 or Vista.)

  • To reproduce the bug, the project must be on an exFAT HDD partition. (At least, it seems that way.)

  • The project/file names mentioned below ("VS2010exFatBug" etc.) are not important; they just make the instructions more explicit.

Download the sample project:

How to create an exFAT HDD:

  • First, Do not use a memory card; at least not a typical slow one; they do not seem to trigger the problem.

  • We have reproduced the problem on exFAT HDDs and virtual-HDDs of sizes 10GB, 20GB and 130GB, all with default cluster sizes, etc..

  • The Format GUI will not offer exFAT for drives unless they are mounted as "removable;" however, if you don't have a removable HDD then you can still format a fixed HDD using the command-line.

    If X: is the drive to be formatted, use format X: /FS:exFAT

    (Formatting the drive will erase all data on it. Don't do this if you don't know what you're doing.)

  • If you're using VMware, you can add a new virtual HDD to the machine, give it a drive letter via Disk Managament, then format it as exFAT using the command-line command.

  • If you're using BestCrypt or a similar virtual-HDD tool, you can do the same and/or tell the tool to mount the drive as removable and use the GUI.

  • Of course, if you have a spare real HDD/partition -- or even better a real external HDD that mounts as removable -- then you have it very easy. :)

How the sample project was created:

Note: I am not sure exactly which of these steps are important. I think I've got to a simple enough example that I can leave it to the Visual Studio team to investigate further.

Note: You do not have to follow these steps. You can just download the pre-made project (see above). The steps are here to explain how that project was made.

  1. Create a new C++ Win32 "Windows Application" exe project/solution (called "VS2010exFatBug") somewhere on the exFAT drive.

  2. Add new Win32 "DLL" project to it (called "SimpleDll").

    When creating it, turn on the Export Symbols checkbox.

  3. In the exe's main VS2010exFatBug.cpp, add this after the default includes:

    #include "../SimpleDll/SimpleDll.h"

  4. Before the call to InitInstance, add this:


    (That just ensures that the DLL is used. The example fnSimpleDll function already exits in the DLL thanks to the project template.)

  5. Edit the EXE's Linker->Input settings to add this:


  6. In the main VS2010 menus, go to Project -> Project Dependencies, select VS2010exFatBug in the drop-down and then tick SimpleDll in the "Depends on" list.

That's it. Now you should be able to build without any reported errors. Now try to run it and see if you get the error shown at the top of the page. If you don't, rebuild and try again. It should not take many rebuilds before you run into the problem.