(See possible solution at the bottom!)
1. Summarise the issue (what were doing, what went wrong?)
When running Darcs 2.8.1 on Server 2012 environments the process crashes 
(darcs.exe has stopped working) often - about half of the time from the 
same prompt when running from an administrator cmd. This happens when 
issuing the pull command, but before any final decision are made. When 
the process crashes, a lock file is left thus prevent further automatic 
Darcs usage. This has been replicated across 3 server 2012 installations 
on completely different environments. 
The error in the event log indicates a possible error with libcurl

This is the redacted event log for the error: 
Faulting application name: darcs.exe, version: 0.0.0.0, time stamp: 
0x4ffa38a4
Faulting module name: libcurl-4.dll, version: 0.0.0.0, time stamp: 
0x4ffa376d
Exception code: 0xc0000005
Fault offset: 0x0001f80d
Faulting process id: 0x16d4
Faulting application start time: 0x01cfacb57dba928f
Faulting application path: x:\xxx\xxx\darcs\darcs.exe
Faulting module path: x:\xxx\xxx\darcs\libcurl-4.dll
Report Id: bb896967-18a8-11e4-80bc-40f2e9277dc5
Faulting package full name: 
Faulting package-relative application ID: 

2. What behaviour were you expecting instead?


3. What darcs version are you using? (Try: darcs --exact-version)
darcs compiled on Jul  9 2012, at 01:48:23

Context:

[TAG 2.8.1
Ganesh Sittampalam <ganesh@earth.li>**20120514063340
 Ignore-this: fbc024be64f47a743c1336c374f9bb14
]

Compiled with:

HTTP-4000.2.3
array-0.4.0.0
base-4.5.0.0
bytestring-0.9.2.1
containers-0.4.2.1
directory-1.1.0.2
extensible-exceptions-0.1.1.4
filepath-1.3.0.0
hashed-storage-0.5.9
haskeline-0.6.4.7
html-1.0.1.2
mtl-2.1.1
network-2.3.0.13
old-time-1.1.0.0
parsec-3.1.2
process-1.1.0.1
random-1.0.1.1
regex-compat-0.95.1
regex-posix-0.95.1
tar-0.3.2.0
text-0.11.2.0
unix-compat-0.3.0.1
vector-0.9.1
zlib-0.5.3.3

4. What operating system are you running?
Windows Server 2012R2, Version 6.3, build 9600

5. POSSIBLE SOLUTION: 
I used cabal install darcs -f-curl to create a windows binary for 2.8.4 
and then I included the latest libcurl dll's (7.37.0 win64) with the 
binary. 

After distributing this version, the problem stopped occuring on the 
server I was currently having trouble with. 
Here is the exact version of the working Darcs: 
darcs compiled on Jul 31 2014, at 15:53:11

Context:

[TAG 2.8.4
Ganesh Sittampalam <ganesh@earth.li>**20130127231845
 Ignore-this: d032f69540341ecfd5858fce7aee1457
] 

[Resolve issue2155: Expurgate the non-functional annotate --xml-output 
option
Dave Love <fx@gnu.org>**20130127231835
 Ignore-this: eb03207031e75687968091d56fb008f8
 backported from HEAD by Ganesh Sittampalam <ganesh@earth.li>
] 

[Resolve issue2155: Expurgate the non-functional annotate --xml-output 
option
Dave Love <fx@gnu.org>**20130120121739
 Ignore-this: 8a9ce6409a50b71cd0d2fdabbc181b1a
 backported from HEAD by Ganesh Sittampalam <ganesh@earth.li>
] 

[note dependency bumps in NEWS
Ganesh Sittampalam <ganesh@earth.li>**20130120170310
 Ignore-this: 48cf181c89ec1b69fc6e9e701734ff19
] 

[bump version to 2.8.4
Ganesh Sittampalam <ganesh@earth.li>**20130120154856
 Ignore-this: 2f2542e9825b66cda3a0a17275b5e311
] 

[resolve issue2199: getMatchingTag needs to commute for dirty tags
Ganesh Sittampalam <ganesh@earth.li>**20121218191024
 Ignore-this: 947252cd8e084b793044aff564f0462d
 backported from HEAD
] 

[accept issue2199: darcs get --tag gets too much
Ganesh Sittampalam <ganesh@earth.li>**20120528164525
 Ignore-this: 8c138a80c294e6181a3ef9250593fa31
] 

[constrain haskeline version on old GHC
Ganesh Sittampalam <ganesh@earth.li>**20130119234432
 Ignore-this: 8af00cc3d3c1ad223a8b35712c06bae
] 

[Add option -a to darcs changes in Setup.lhs
Ben Franksen <ben.franksen@online.de>**20120811195807
 Ignore-this: f23d2e558f7248fec8d07b0391d9a7e8
 
 Some (potential) contributors (like me) have 'changes interactive'
 in their ~/.darcs/defaults and then wonder why their build hangs.
] 

[add copyright notices for the imported haskeline code
Ganesh Sittampalam <ganesh@earth.li>**20130119163610
 Ignore-this: afcdc8048f8b3233fa17d3ab0c9c311f
 licence/copyright taken from haskeline 0.6.4.7:
 BSD3, copyright Judah Jacobson
] 

[import encoding code from haskeline: switch over
Ganesh Sittampalam <ganesh@earth.li>**20130118231907
 Ignore-this: b423a92ba93e74520d0578ac21aceab3
] 

[import encoding code from haskeline: source files
Ganesh Sittampalam <ganesh@earth.li>**20130118225947
 Ignore-this: c2d1e228fa4cce3e66e90a14fa2f3200
] 

[import encoding code from haskeline: cabal file changes
Ganesh Sittampalam <ganesh@earth.li>**20130118070642
 Ignore-this: d2ed13887d0c547cb7498bd5a2aef46f
] 

[import encoding code from haskeline: Setup.lhs changes
Ganesh Sittampalam <ganesh@earth.li>**20130115181040
 Ignore-this: 31ccdca76001bff769464fb7a8e574e9
] 

[ROLLBACK: conditionally use bytestring-handle
Ganesh Sittampalam <ganesh@earth.li>**20130111213829
 Ignore-this: d3c18b61f765bdfcb574b4977185197b
 It doesn't skip invalid byte sequences when decoding so breaks on 
 repositories with non-UTF8 encoded metadata.
] 

[bump network dependency
Ganesh Sittampalam <ganesh@earth.li>**20130111184607
 Ignore-this: 54e55fa09793008d55572b6acad1a7b8
] 

[add some comments about "nearby" darcs, and print out the one that was 
found
Ganesh Sittampalam <ganesh@earth.li>**20130111211817
 Ignore-this: 57385f3248fc539435ed9de069a40bd5
 backported from HEAD
] 

[make darcs-test look "nearby" for a darcs exe to use
Ganesh Sittampalam <ganesh@earth.li>**20130111211445
 Ignore-this: d952cf330c0d9510c5c973dd41b191e0
 backported from HEAD
] 

[need different path separator on Windows
Ganesh Sittampalam <ganesh@earth.li>**20121219191221
 Ignore-this: 42c7ba1e46f5b6b600d23838e5a162cb
] 

[test for issue2286: make sure we can read repos with non-UTF8 metadata
Ganesh Sittampalam <ganesh@earth.li>**20130102222735
 Ignore-this: adc6165d5d5d991383ebf0e6547f7bf4
] 

[We can use chcp to switch encodings on Windows
Ganesh Sittampalam <ganesh@earth.li>**20130101122254
 Ignore-this: bc115467e31e144694a33e43dca3fb6c
 This means that the tests that require different encodings can run.
] 

[Find latin9 locale on OS X too
Michael Hendricks <michael@ndrix.org>**20120420202408
 Ignore-this: c87db3b97312234ed2380d2ca11a8ca0
 
 Most Linux systems describe latin9 as "iso885915".  OS X
 describes it with "ISO8859-15".  The new regex catches both.
] 

[windows test fix: replace shell script with a Haskell program
Ganesh Sittampalam <ganesh@earth.li>**20121231224332
 Ignore-this: de01ab8647e7d62c18d8c266d514b054
] 

[unsetting DARCS_TEST_PREFS_DIR in utf8 test doesn't seem to be 
necessary
Ganesh Sittampalam <ganesh@earth.li>**20130101120246
 Ignore-this: ed74710d8b358b920d742e86a7f008d8
 
 It was causing problems on Windows because getAppUserDataDirectory
 still returns the normal user directory.
 
 It also means that the repository type choice isn't picked up.
] 

[improve diagnostics when utf8 test fails
Ganesh Sittampalam <ganesh@earth.li>**20121231224600
 Ignore-this: 63db587bc36f8826c66dc6913a4fdb2d
] 

[need to do case-insensitive comparison on Windows
Ganesh Sittampalam <ganesh@earth.li>**20121228214823
 Ignore-this: ef309d4aef22e87d5c3da3222926af0e
] 

[update NEWS
Ganesh Sittampalam <ganesh@earth.li>**20121216202654
 Ignore-this: aef3e47204a4157504f90554ffc3a327
] 

[conditionally use bytestring-handle instead of haskeline for encoding
Ganesh Sittampalam <ganesh@earth.li>**20121216201745
 Ignore-this: fd758796b689d090d01e003e660e405
 This is transitional because we need to support GHC 6.10: we can switch
 over to bytestring-handle unconditionally on HEAD.
] 

[bump deps for GHC 7.6/latest hackage
Ganesh Sittampalam <ganesh@earth.li>**20121216201543
 Ignore-this: 77829b074a4bff635a421879bdd04be0
] 

[conditionally support tar 0.4
Ganesh Sittampalam <ganesh@earth.li>**20121216201014
 Ignore-this: 8eff0330e6af196727bdd736ef31db25
] 

[recent test-framework seems to require Typeable
Ganesh Sittampalam <ganesh@earth.li>**20121216175601
 Ignore-this: a8cce6b69984bfc2335b5c19688950b3
] 

[stop using Prelude.catch
Ganesh Sittampalam <ganesh@earth.li>**20121216163240
 Ignore-this: b4bfc48775b3337f8f7ebe275be1a058
 
 backported from HEAD
] 

[import constructors of C types to deal with a GHC change
Ganesh Sittampalam <ganesh@earth.li>**20120401132500
 Ignore-this: ab7cf2fb5e9a2494c14fe7394200da9b
] 

[TAG 2.8.3
Ganesh Sittampalam <ganesh@earth.li>**20121104174910
 Ignore-this: 3198f6deecf3d1b44df6e05a2657d9ca
] 

Compiled with:

HTTP-4000.2.8
Win32-2.3.0.0
array-0.4.0.1
base-4.6.0.1
bytestring-0.10.0.2
containers-0.5.0.0
directory-1.2.0.1
extensible-exceptions-0.1.1.4
filepath-1.3.0.1
hashed-storage-0.5.11
haskeline-0.7.1.3
html-1.0.1.2
mtl-2.1.2
network-2.4.1.2
old-time-1.1.0.1
parsec-3.1.3
process-1.1.0.2
random-1.0.1.1
regex-compat-0.95.1
regex-posix-0.95.2
tar-0.4.0.1
text-0.11.3.1
unix-compat-0.4.1.1
vector-0.10.0.1
zlib-0.5.4.1

I have attached a screenshot of the dll's and the versions

Attachments

• darcs-dlls.png

Compiling with -f-curl was my first thought too. Note that then it won't 
depend on libcurl, so I wouldn't expect you to need the libcurl DLLs at 
all.

Using libcurl should improve the performance of HTTP downloads, but if 
performance is acceptable without it, I'd be inclined to suggest you 
just use that workaround.

At some point we'd like to replace the downloading code with something 
that uses pure Haskell, in part to avoid this kind of messy C dependency 
that's hard to use on Windows.