Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Migrating to Windows 7 x64, I'm having problems running Cygwin in this environment. It looks like ASLR feature of Windows 7 is the cause. It causes various DLLs to load at different addresses in virtual memory, and it looks like Cygwin expects to have the same base addresses for the same DLLs in the parent and child processes, when a child process is spawned. Apparently there is a specific check for that and the following message is displayed:

5816 [main] perl 4148 C:\Cygwin\bin\perl.exe: *** fatal error - unable to remap C:\Cygwin\lib\perl5\5.10\i686-Cygwin\auto\Data\Dumper\Dumper.dll to same address as parent(0x9A0000) != 0xB40000

I tried turning off ASLR by setting HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages: DWORD to 0, but it doesn't seem to do anything: the DLLs are still loaded into random places (verified by the above message and by looking at the address space of the both processes using Process Explorer)

While in the meantime I'm planning on using XP Mode for running Cygwin, it seems a bit artificial and create some limitations.

Does anyone know of a way to run Cygwin directly under Windows 7 x64?

share|improve this question
    
Have you tried running Cygwin in "compatibility mode"? –  Reuben Sep 12 '09 at 22:04
    
Yes. Also as Administrator (i.e. in elevated mode). Neither of them help :( –  Rom Sep 12 '09 at 22:27
add comment

3 Answers

up vote 4 down vote accepted

had the same problem under Windows 7 64-bit, rebase solves it:

share|improve this answer
    
that does it, thanks! –  Rom Sep 19 '09 at 21:59
add comment

perlrebase (I am the maintainer and author)

Not yet verified:

  • If you still get fork errors, try to clear the ASLR flag in the dll's.
    peflags -d0 in all dll's (e.g. your rebase.lst)

I'm trying this now, and if it helps I'll release a new perl version.

share|improve this answer
add comment

It's one of those few situation in which you will need Windows XP Mode, and not XP Compatibility. Hopefully your processor meets the requirements; You'll need a processor that supports hardware virtualization.

To be sure run the appropriate tool below.

  • Intel Processor Identification Utility
  • AMD Virtualization System Compatibility Utility

Note XP Mode is still in release candidate Mode. At least on my 32-bit machine it behaves nicely. I'm confident you will have a similar experience on your x64.

EDIT: I can only post one hyperlink per answer until I'm no longer a new user. So the links go on a comment to this post

share|improve this answer
    
    
You did say you were planning it, not already running it under XP Mode. In any case what limitations can that possibly be? XP Mode is a full virtualization mode. The program has no way of knowing it is in a VM environment. –  A Dwarf Sep 13 '09 at 17:57
    
this is irrelevant to the original question, but just in case it can be useful for somebody, here are limitations of running in XP mode for me: a) x64 mode is not available in Win7 XP Mode b) there is only one CPU available there c) one particular tool works with the local disks differently than with mapped "network" disks, and therefore I need to run it on the main machine. All these problems have a workaround or can be tolerated, but the real solution is preferred –  Rom Sep 14 '09 at 5:34
add comment

protected by Diago Dec 1 '10 at 7:17

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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