stack ghci can't load pthread unless running as Administrator

Question

When I run stack ghci on a brand-new project, it fails to load:

$ stack new repro simple
Downloading template "simple" to create project "repro" in repro\ ...

(Additional output omitted to make the question more readable.)

$ cd repro/

$ stack ghci
Using main module: 1. Package `repro' component repro:exe:repro with main-is file: C:\Users\mark\Desktop\repro\src\Main.hs
Building all executables for `repro' once. After a successful build of all of them, only specified executables will be rebuilt.
repro> configure (exe)
Configuring repro-0.1.0.0...
repro> initial-build-steps (exe)
Configuring GHCi with the following packages: repro
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 5))
Whilst trying to load:  (dynamic) pthread
Additional directories searched:   C:\\Users\\mark\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20180531\\mingw64\\lib
   C:\\Users\\mark\\AppData\\Local\\Programs\\stack\\x86_64-windows\\msys2-20180531\\mingw64\\bin
   C://Users//mark//AppData//Local//Programs//stack//x86_64-windows//ghc-8.6.5//mingw//bin/
   C://Users//mark//AppData//Local//Programs//stack//x86_64-windows//ghc-8.6.5//mingw//bin/../lib/
   C://Users//mark//AppData//Local//Programs//stack//x86_64-windows//ghc-8.6.5//mingw//bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/
   C:/Users/mark/AppData/Local/Programs/stack/x86_64-windows/ghc-8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/
   C:/Users/mark/AppData/Local/Programs/stack/x86_64-windows/ghc-8.6.5/mingw/bin/../lib/gcc/
   C:/Users/mark/AppData/Local/Programs/stack/x86_64-windows/ghc-8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/
   C:/Users/mark/AppData/Local/Programs/stack/x86_64-windows/ghc-8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../lib/
   C:/Users/mark/AppData/Local/Programs/stack/x86_64-windows/ghc-8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/
   C:/Users/mark/AppData/Local/Programs/stack/x86_64-windows/ghc-8.6.5/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../
   C:\Windows\system32

This is on Windows 10 (x64). I have another machine with a similar OS configuration and stack version, and on that machine, I have no problems. This seems to be an environment issue, but I can't figure out what it is.

I'm running from Git Bash, and if I run it as Administrator, it works:

$ stack ghci
Using main module: 1. Package `repro' component repro:exe:repro with main-is file: C:\Users\mark\Desktop\repro\src\Main.hs
Building all executables for `repro' once. After a successful build of all of them, only specified executables will be rebuilt.
repro> initial-build-steps (exe)
Configuring GHCi with the following packages: repro
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( C:\Users\mark\Desktop\repro\src\Main.hs, interpreted )
Ok, one module loaded.
Loaded GHCi configuration from C:\\Users\\mark\\AppData\\Local\\Temp\\haskell-stack-ghci\\2524149e\\ghci-script
*Main>

I've been working with Stack for years on Windows, and this is the first time I've have to run as Administrator, and it really bothers me. What could be the issue, and how do I address it?

FWIW, this is the Stack version:

$ stack --version
Version 2.1.3, Git revision 0fa51b9925decd937e4a993ad90cb686f88fa282 (7739 commits) x86_64 hpack-0.31.2

This is the same version as I have on the other machine where the issue doesn't appear.

Examples here are copied from running Git Bash, but the issue is the same if I use cmd.

Answer 1

Thanks to Fyodor Soikin, I was able to track down the issue.

Summary

Give your user account Read & execute permissions to pthread.dll.

Details

I didn't understand why this new machine of mine exhibited this problem while another machine with the same OS and basically the same setup didn't have any problems.

On close inspection, it turned out that that other machine didn't have a pthread.dll file at all.

It did have quite a few copies of pthread.h, though, and I suppose that this was enough to enable Stack to build the code.

The new machine had pthread.dll in a few places, including a subdirectory of C:\Windows\System32\DriverStore, which implies to me that this file originally arrived via a driver that the new machine uses, but the old machine didn't have. It also has a copy of pthread.dll in C:\Windows\System32, but this file was extraordinarily locked down. My own user account didn't have Read or Execute rights to the file, but I could view and change the permissions in Administrator mode.

I gave the local Users group Read & execute rights to the file, after which everything seems to work as it's previously done on my other machines.