I updated my cygwin using the setup-x86_64.exe tool (version 2.873) on Windows 7.
I needed to install some additional packages (mostly zip/unzip etc).
Since then, I am getting the following errors when I try to run the Cygwin Terminal (the shortcut points to C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -):
Error: could not fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall / rebase --help'.
I searched online how to run the rebaseall command they advise in the message. Essentially the recommendation was to start cygwin/bin/dash.exe and run:
bin/rebaseall
I did that a few times, I also used the -v comment, and no errors come back. Still I can't start cygwin.
I also tried running cygwin-x/XWin-server nothing happens.
I looked at the setup logs in cygwin/var/log/setup.log I can't see any error.
I tried to run the setup program a few more times reinstalling some of the packages I already had, that didn't help neither.
Any ideas how can I get that to work?
Here is the fix.
Go to you Windows Defender Security Center settings
Click on App & Browser Control
At the bottom click on the "Exploit Protection Settings" link
Go to "Program Settings" and click on the "Add program to
customize" -> "Choose exact file path"
Navigate to "C:\Program Files\Git\usr\bin\sh.exe" and add it
Override and turn off the following: Mandatory ASLR, Randomize memory allocations (Bottom-up ASLR)
Click "Apply" and now everything should work fine.
Also add these other binaries from the same folder: expr.exe, uname.exe, grep.exe, rm.exe
Good luck,
Gabriel
One of my colleagues has similar errors when openening the terminal from SourceTree (Mingw32), and also got errors when trying to pull, rebase, etc (anything not local). He solved it by uninstalling Sourcetree, using CCleaner to clean his registries (not sure if this was required), rebooted and installed Sourcetree again.
I know this is slightly different from the problem described by the OP, but it might still be solvable by un/re-installing and cleaning of registries, and this might also help future people finding this question with the Sourcetree issue (like I did).
Edit:
Another colleague had the issue as well, and he managed to fix it merely with a restart without any un/re-installation or using CCleaner.
I've been suffering similar problems a lot recently. I've been unable to determine the cause, whether it's due to a recent Windows7 patch or an update in the latest cygwin. I'm in a tightly controlled corporate environment with only limited elevated rights, a lot of anti-malware and encrypted drives. I'm using 32-bit Cygwin at present.
Issues for me began after I installed Git and Git-Svn packages, which required Perl and upgraded various other Cygwin packages as well.
Rebasing using rebase-trigger or rebaseall did not solve the issue for me. Neither did re-installing and setup repeatedly raised errors in the post-install pahse when trying to do the rebase itself.
My first success was by downgrading Perl to the previous version, ie. down to 5.22.1.2 from 5.22.2.1. After a couple of weeks the error returned, perhaps after a compulsory windows update and reboot.
My latest success has been achieved by ignoring the dash/rebaseall script and running rebase.exe directly as follows:-
Create a file which lists all cygwin .dlls in the /bin directory except cygwin1.dll and cyglsa.dll ie.
$ cd /bin
$ ls -1 *.dll | egrep -v '(cygwin1|cyglsa).*\.dll' >rebasedlls.txt
Close all cygwin terminals, if you have any services running which use cygwin ensure that those are stopped also. Check TaskManager and kill processes if necessary.
Open a cmd.exe window (it may help to use whatever elevated rights you can muster), change to the windows path of your cygwin /bin directory (ie. the windows directory of cygpath -wa /bin).
Use rebase.exe directly to find the base address of the cygwin1.dll file:
C:\apps\cygwin\bin> rebase.exe --info cygwin1.dll
/usr/bin/cygwin1.dll base 0x61000000 size 0x00500000
Using that base address and the size as a guide I chose the next whole value up as my rebase base address, 0x62000000. No particular reason for this, just a hunch. (The rebaseall script uses 0x70000000).
Use rebase.exe to fix all the .dlls listed in the file from step (1):
C:\apps\cygwin\bin> rebase -b 0x62000000 -4 -n -v -t -T rebasedlls.txt
So far, so good, my Cygwin is back to a working state again.
From https://chromium.googlesource.com/chromium/src/+/master/docs/cygwin_dll_remapping_failure.md
Handling repeated failures of rebaseall to allow cygwin remaps
Sometimes DLLs over which cygwin has no control get mapped into cygwin
processes at locations that cygwin has chosen for its libraries.
This has been seen primarily with anti-virus DLLs. When this occurs,
cygwin must be instructed during the rebase to avoid the area of
memory where that DLL is mapped.
Background
Some background for this is available on
http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable-to-remap/
Because of unix fork semantics (presumably), cygwin libraries must be
mapped in the same location in both parent and child of a fork. All
cygwin libraries have hints in them as to where they should be mapped
in a processes address space; if those hints are followed, each
library will be mapped in the same location in both address spaces.
However, Windows is perfectly happy mapping a DLL anywhere in the
address space; the hint is not considered controlling. The remapping
error occurs when a cygwin process starts and one of its libraries
cannot be mapped to the location specified by its hint.
/usr/bin/rebaseall changes the DLL hints for all of the cygwin
libraries so that there are no inter-library conflicts; it does this
by choosing a contiguous but not overlapping library layout starting
at a base address and working down. This process makes sure there are
no intra-cygwin conflicts, but cannot deal with conflicts with
external DLLs that are in cygwin process address spaces
(e.g. anti-virus DLLs).
To handle this case, you need to figure out what the problematic
non-cygwin library is, where it is in the address space, and do the
rebase all so that no cygwin hints map libraries to that location.
Details
Download the ListDLLs executable from
sysinternals
Run it as administrator while some cygwin commands are running.
Scan the output for the cygwin process (identifiable by the command) and for
DLLs in that process that do not look like cygwin DLLs (like an AV). Note
the location of those libraries (there will usually only be the one).
Pick an address space location lower than its starting address.
Quit all cygwin processes.
Run a windows command shell as administrator
cd in \cygwin\bin
Run ash /usr/bin/rebaseall -b <base address> (This command can also take a
-v flag if you want to see the DLL layout.)
That should fix the problem.
Failed rebaseall
If you pick a base address that is too low, you may end up with a broken cygwin
install. You can reinstall it by running cygwin's setup.exe again, and on the
package selection page, clicking the "All" entry to Reinstall. You may have to
do this twice, as you may get errors on the first reinstall pass.
I have Administrator access to my PC. For me the solution to this was to run the Cygwin session as Administrator -- right the icon, run as administrator, as shown here:
After running as Administrator the first time, new Cygwin sessions started up without hassle.
There is a rebase utility that triggers the rebase as post-setup phase.
From dash or bash:
/usr/bin/rebase-trigger full
close all process and run again setup-x86_64.exe.
uninstall it,
and install the software for 32-bit.
I restarted 3 times, and then it was fine. wtf Windows 7
This exact same error message has various causes, not all of them related to setup-x86_64.exe, although I have seen it in that context as well. But if rebaseall didn't fix your problem, here's a suggestion that might work.
In the case I saw this morning, it turned out to have been caused by having a couple of processes that continued to run after I exited the mintty terminal emulator. My hunch is that these zombie processes prevent the console from being recycled. In my case, the two processes were determined experimentally, by reviewing a list of running processes for stray processes that are no longer needed. I found the two processes that were blocking me by reviewing the list of running tasks.
C:\WINDOWS\system32>tasklist | grep Console
CobraWinLDTP.exe 31844 Console 1 43,600 K
geckodriver.exe 52640 Console 1 32,164 K
C:\WINDOWS\system32>taskkill /F /PID 31844
SUCCESS: The process with PID 31844 has been terminated.
C:\WINDOWS\system32>taskkill /F /PID 52640
SUCCESS: The process with PID 52640 has been terminated.
I saw on some other stackoverflow questions that git is often the zombie process that causes this symptom (for some users). Unfortunately, any residual process that survives after your console session is closed can cause this problem, so you have to experiment.
Go to The Task manager
Kill 'Git for Windows' process
Reopen your git bash
It seems that all is working fine.
NOTE: In case you don't find 'Git for Windows' process and still have to face the same just kill 'Node.js: Server-side JavaScript' process instead
If you have turned Force randomization for images (Mandatory ASLR) on in Exploit protection of Windows Security, then you can turn it off by selecting Use default (Off) to address this issue.
My instance of this problem was also related to having turned on 'force randomization for images' in the Windows Security exploit protection settings.
After you change the setting back to the default off position and reset, you will have to run Git as an administrator in order to effect directory changes which apparently require elevated permission.
I wasn't able to determine a way to allow that setting to be turned on and not get this issue with Git though I played around with it for a while unsuccessfully.
Turning even optional security features off to get a single program working seems like a last resort option to me. However, this isn't just any program either.
I am trying to get some code running which uses make. I've downloaded and installed both MinGW (standard 32 bit) and TDM-GCCs flavor of MinGW on my 64-bit Windows 7 machine.
When I run make (i.e. mingw32-make.exe) in Administrator mode, I get the following error message:
Windows cannot access the specified path, or file. You may not have the appropriate permissions to access the item.
The weird/scary part is that, upon running, it immediately deletes the exe file.
I ran a checksum SHA1 as recommended in the comments using the Microsoft (R) File Checksum Integrity Verifier V2.05:
C:\path\to\folder>fciv.exe -sha1 mingw32-make.exe
//
// File Checksum Integrity Verifier version 2.05.
//
c8ae5c780ab7bed652883d6443b5bfe5e23d30c9 mingw32-make.exe
I don't understand what this output means, but maybe it's helpful to someone.
Notes:
This happens regardless of where the file is located on my pc.
This behavior is specific to the make program (others such as gfortran and gcc appear to be working fine)
Renaming the file makes no difference.
I am an administrator on the pc
Same behavior when I run the program from the explorer or command line.
My anti-virus program (Avast) does not detect any problems with the file when I scan it.
I got the MinGW setup file from this SourceForge page.
I got the TDM-GCC web installer from this page.
The file size is 219,662 bytes (from both the main MinGW and TDM-GCC packages)
I have run make from the command line where I have started the command prompt by way of selecting Run as Administrator in the context menu.
I have also tried to run make by selecting Run as Administrator when I have it selected.
I run the command mingw32-make when this behavior occurs. I have also tried renaming it to things like make and foo with the same result.
The first time this happened with both MinGW it deleted the original file and I re-installed it using the mingw-get application. From thereon after I started making copies of the original mingw32-make for testing.
For the make executable, I have all permissions (including Read & execute) except the special permissions field.
After using the process manager I found out it was indeed Avast that was the problem :S A couple of lines revealed avast actually deleted the file before windows got around to executing it, which was the reason for the windows message. I put Avast on 'Silent Mode' a while back; I thought the only purpose of this mode was to suppress notifications about minor updates, but apparently it also gave Avast permission to deal with 'threats' silently as well.
After figuring that out the solution was straightforward. I just went into the settings and created an exception for the mingw32-make.exe file. It now runs without issue.
Thanks very much for your help everyone!
User account has administrator privilege but when user started to work , not all privilege are taken in account , just start your application for compiling with run with administrator mode try this : https://technet.microsoft.com/en-in/library/cc781763(v=ws.10).aspx
I downloaded bitcloud, the atmel zigbee stack and I am trying to compile one of the default applications, ZLLDemo.
It is located currently at:
C:\Users\Ryan\Desktop\BitCloud_MEGARF_3_1_0\Applications\ZLLDemo\atmelStudio_projects\ATmega256RFR2.cproj
Everytime I try to compile the application I get a windows message screen for "mkdir.exe" error 0xc0000142. In the Output screen I see the line "make: *** [directories] Error -1073741502"
This same error and error code occurs later in the build process for cp.exe if I manually make the folders myself.
I have tried the following things to fix the error:
Change folder and contents to different owners, everyone having full
privileges
run make command manually from a command prompt window as admin
clean solution before retrying
all other examples files
ran directly from C: as "C:\BitCloud_MEGARF_3_1_0\Applications\ZLLDemo\atmelStudio_projects\ATmega256RFR2.cproj" - as per general suggestion for the windows error I tried
"sfc /scannow" in case mkdir had somehow been corrupted
Changed AppInitDLLs Reg key to 0 to load all DLLs at start of application
Disabled Internet security
Does this have a general fix or is there perhaps something else at work here? General compilations work, its just external ones. My friend did the same and it seems to work just fine for him.
Windows 8.1
Atmel Studio 6.2
Avrfreaks had a solution that I finally found here.
Their solution is to download an old version of the msys file for winavr. Which means that their is something more than likely wrong with the latest version of winavr for windows 8.1
sebastor wrote:
I found solution.
Copy this file:
http://www.madwizard.org/download/electronics/msys-1.0-vista64.zip
to utils\bin directory (WinAVR)
During linking I get this message:
LINK : fatal error LNK1101: incorrect MSPDB120.DLL version; recheck installation of this product
I have seen solutions for similar errors on previous versions of VC2013 but those did not work for me. Those include:
running C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat
adding %VS120COMNTOOLS% environment variable to the PATH environment variable
Reinstall or Repair the installation of MSVC2013 (NOT RECOMMENDED)
The first time I got this error I went ahead with a full reinstall of VC2013. I chose to take this rout because I thought maybe I had screwed up the install by installing older versions of VC after installing VC2013. Although reinstalling worked the first time, I can't recommend doing this. The MS installer seems rather broken and hung up on me on repeated attempts, resulting in the loss of 5+ hours of my life.
What are some other solutions to this problem if the first 2 options do not work?
Open Task Manager.
Check for the currently running processes mspdbsrv.exe and kill it if it is running and try again. I don't know why this works, but I have to do it every once in a while. The process comes back each time you compile and it seems random whether or not it gets stuck on this step.
Alternatively, if you do not need debug information generated, you can skip this process altogether by setting:
Project Properties -> Linker -> Debugging -> Generate Debug Info ->
No
I just had this happen. In my case, I had a statically-linked shared 'helper' lib that was compiled with the cl.exe CRT flags "-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE", whereas my target app that linked in this helper lib did not have these set. Once I added these flags to the app's cl.exe flags, all was good.
I get this error message when another compile (jenkins) is still running in the background.
Waiting for it to finish, and retry fixes the error.
I'm trying to automatically download Nuget.exe from a Rakefile, in order to minimize the amount of initial setup needed to run my samples on GitHub.
I've understand how to download a file (I'm using HTTParty) and how to save a binary file (using the b flag on File.new) but now I've got problem running Nuget.exe. In particular:
if I launch it directly or from PowerShell, the executable runs fine;
if I launch it from cmd or from a Rakefile (which in turn runs cmd), Windows tells me that the program "stopped working".
I reproduced the same behavior with the Nuget bootstrapper, so I thought that the cause was some configuration in my computer.
It then occured to me that I installed ansicom, a library to handle ANSI sequences. I disabled it and then Nuget started without any problem.