I'm using Make from the MinGW distribution. It has always worked, but recently I've gotten the following error:

> make clean
make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x0040b0ac)

And the respective part looks like this:

    del /S /Q *.o > nul
    del /S /Q *.cy.c > nul
    del /S /Q *.pyc > nul
    del /S /Q *.pyo > nul
    if EXIST build (rmdir /S /Q dist > nul)

I have no idea what causes this. Especially because it always has worked perfectly fine.


I was starting to get an exception as well:

make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4227d3)

Might be a different reason, but this problem is apparently caused when the PATH variable contains parentheses (, ), as it does on Win Vista/7. Unfortunately, the available GNU for Windows is hopelessly outdated.

My problem was fixed by forcing make use the correct shell: insert the following line at the beginning of your makefile.

| improve this answer | |
  • Great solution , but I don't know why it was not working , I don't have parentheses in my Environment variables – forsubhi Jan 4 '14 at 13:43
  • 1
    Might be related to the length of the PATH too? In my case, my PATH already had lots of parentheses without any problems (until I installed some more stuff); replacing all instances of C:\Program Files with C:\PROGRA~1 and C:\Program Files (x86) with C:\PROGRA~2 fixed the problem for me. +1 :-) – Cameron Jan 8 '14 at 2:30
  • I also had this issue, and switched to a newer version of make: equation.com/servlet/equation.cmd?fa=make - This did not fix the problem, but it handles the exception better and tells you what is happening: sh: C:\Program: No such file or directory is the first line I get if I don't pass in the SHELL variable. Basically each instance of "Program Files" on the PATH contains a space that isn't escaped properly (as far as make is concerned). It is not the length of the path, but the spaces that are causing this issue. This explains why using a macro without spaces fixed it. – Johannes Jan 24 '16 at 2:50
  • This solution worked for me. – Robert Stiffler Mar 31 '17 at 13:37

I had that issue when I added Git's bin directory to the PATH environment variable. The reason seems to be that Git ships with a version of MSYS and that seems to conflict with MinGW (maybe it doesn't conflict when it's the right version of MSYS and/or MinGW but that's just guessing).

So make sure that there is no (other) MSYS distribution in your PATH.

| improve this answer | |
  • 1
    Git path to bin directory was the issue for me! Well done ! – TridenT Jul 29 '14 at 12:40

Futher to Norbet P.'s answer, I found that adding:


to the top of my Makefile fixed this particular problem for me.

| improve this answer | |
  • 1
    I'm not giving a -1, but this is a horribly bad answer. You cannot just reset PATH!!! this is very bad practice! some times program compilation depends on information in PATH. – The Quantum Physicist Mar 18 '15 at 12:30

This make bug is fixed at least in

GNU Make 3.82
Built for i686-pc-mingw32


| improve this answer | |
  • Where do I get this version from ? – SHOUBHIK BOSE Jun 23 '14 at 14:02
  • 1
    IIRC, I got it from here. – Armali Jun 24 '14 at 13:33

I used GnuWin until I realised last release was posted back in 26 Nov in 2006 . Thats a bit lame, and caused such problems as seen above. Setting SHELL=C:/Windows/System32/cmd.exe does solve some problems but running such old code on new operatingsystems feels unsafe

MinGw is a safer bet. MinGw is acronym for "Minimalist GNU for Windows" and is up to date and includes make and other tools


| improve this answer | |
  • 1
    Did you even read the question? – orlp Aug 20 '13 at 13:16

The Windows error code 0xC0000005 indicates an access violation, or segmentation fault.

  • Is your MinGW installation corrupted?
  • Is your system configured properly? Have any system settings changed recently?
  • Are there hardware problems on your system? You may need to scan the hard drive using CHKDSK or perform a memory test such as Memtest86+.
| improve this answer | |

I noticed in my compile logs that "SHELL=sh" was being passed to make, even though I am on windows platform. My Makfile looked like this:

ifneq (,$(findstring win,$(RDI_PLATFORM))) SHELL = CMD endif

Once I commented the ifneq and end it started working. Not sure why the platform was not interpreted correctly.

| improve this answer | |
  • 1
    This is not an answer to the original question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. – DavidPostill Nov 11 '14 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.