Git Bash Fails to Launch on Windows 11 VM with Parallels Desktop -- Access Violation in msys-2.0.dll

Environment:

• Host: macOS (15.7)
• Parallels Desktop Version: 26.0.1 (57243)
• Guest: Windows 11 Professional (latest cumulative update as of 13 September 2025)
• Git Version: 2.51.0 (msys2-based)

Steps to Reproduce:

1. Create a fresh Windows 11 Professional VM in Parallels Desktop.
2. Install the latest cumulative Windows updates.
3. Install Git for Windows (2.51.0)
4. Attempt to launch Git Bash.
5. Run `git update-git-for-windows` from PowerShell or Command Prompt.

Observed Behaviour:

• Git Bash does not start.
• Running `git update-git-for-windows` returns error code 5.
• On WinDbg, the process crashes in `msys-2.0.dll` with an access violation in `timegm`.

Additional Experiments and Findings:

• On a clean Windows 11 Professional VM in VMware, both Git Bash and `git update-git-for-windows` work correctly.
• Converting the Parallels VM to VMware allows Git Bash to run and `git update-git-for-windows` to succeed.
• This indicates that the Parallels VM environment may be interfering with MSYS2/MinGW runtime and Git's self-update mechanism.

Debug Evidence (from WinDbg):
```
FAULTING_MODULE: msys_2_0.dll
EXCEPTION_CODE: 0xc0000005 (Access violation)
FAULT_ADDRESS: msys_2_0!timegm+0x581
STACK_OVERFLOW: Detected in msys_2_0.dll
PROCESS: bash.exe
```

Inference:

• The issue appears specific to Parallels Desktop VMs.
• Likely causes include:
  • MSYS2 runtime incompatibility with Parallels virtual hardware or certain memory access patterns.
  • Interference with Git's self-update functionality (`git update-git-for-windows`).

Impact:

• Prevents launching Git Bash on Parallels Windows 11 VMs.
• Breaks Git self-update command.
• Affects MSYS2 or MinGW-based tooling inside Windows 11.

 

I have tried to attach the WinDbg output file but it will not let me. Nor will it let me place the contents of the log file within a code block.

 

I'm seeing the same issue with Windows 11, Parallels 26 and latest Git for Windows both installed by Chocolatey and its own installer.
Reduced it down to an issue with forking subshells, e.g. something like HOSTNAME=$(hostname) causes an immediate crash.
I don't have VMware so wasn't able to confirm whether it works there.
AI suggested it might be to do with Mandatory ASLR, but these settings are defaulting to off anyway in my installation.

 

Forgot to mention in previous post, running bash --norc e.g. from Powershell will get it running, and it's find until you try and run a script which uses the output from subprocesses.

 

Migrated the VM to VMware and same experience as DamienB2 - magically Git bash now runs as expected, so it does indeed appear to be a Parallels issue.
Note that uninstalling Parallels Tools and Parallels Toolbox from the original Parallels VM did not fix it, so it's something more fundamental than the DLLs those may be injecting.

 

This issue has been around for me for quite some time. Using an older runtime worked for a while but is no longer a valid workaround. MSYS2 setup itself fails with the same access violation.