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.


7 Answers 7


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.

  • Great solution , but I don't know why it was not working , I don't have parentheses in my Environment variables
    – forsubhi
    Jan 4, 2014 at 13:43
  • 2
    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, 2014 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, 2016 at 2:50
  • This solution worked for me. Mar 31, 2017 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.

  • 1
    Git path to bin directory was the issue for me! Well done !
    – TridenT
    Jul 29, 2014 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.

  • 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. Mar 18, 2015 at 12:30

This make bug is fixed at least in

GNU Make 3.82
Built for i686-pc-mingw32


  • Where do I get this version from ? Jun 23, 2014 at 14:02
  • 1
    IIRC, I got it from here.
    – Armali
    Jun 24, 2014 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


  • 1
    Did you even read the question?
    – orlp
    Aug 20, 2013 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+.

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.

  • 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, 2014 at 21:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .