I don't have any of the Haskell tooling currently installed.
I cloned one of my projects, navigated to it and did stack init

After this I get a generic crash with no information given.
I've let stack.exe through the firewall and it's running as admin.

This is likely a network thing because I had trouble with it previously (cabal installed by MinGhc crashed on cabal update).

Tell me what I can do to get you more info on this.

Try re-running with -v which will print debug information. :-)

Also, please run stack --help and stack --version to confirm that a non-network operation completes without crashing.

stack --help and stack --version ran fine, the version is Version 0.1.0.0, Git revision c2e5af39679439921570552e3e722f6819f4f4bf

stack init -v outputs this before crashing

Have you been able to run any Haskell network-using apps successfully in the past on this machine?

I have been able to run and update cabal before when I installed it via Haskell Platform.

Then this is most likely some bad interaction with newer versions of the network package. Do you have any ability to build a newer version of the network package on that machine and try running some sample programs?

So, should I install HP again and then try building newer versions of network with it?

If you'd find it easier, I can try sending you a simple network-using binary from my Windows machine tomorrow.

Sure, that would be convenient, but I'm very willing to do anything to help resolve this.

Oh, I also have another Windows machine that has HP up and running (my PC) so I can also build binaries on it and send them to the server.

Here's a simple program:

Includes the executable and source code. Can you tell me how that goes?

So it works on my Windows 8.1 machine, crashes on the Windows Server.

That's good news at least, it means we've isolated the problem significantly. At this point though, I'm not sure if the best way forward. Perhaps you could open up an issue against the network package and try to get advice from them on how to isolate this further? I'm not that well versed in how to diagnose these kinds of crashes on Windows.

Yeah, the cabal update crashes also seemed to point the same way.

I can reproduce on AppVeyor (#457) I'll test server 2015 and report results

@rvion@LukaHorvat would one of you be able to open up an issue upstream with the network package, since you've each been able to reproduce this?

I opened the issue and decided to see which version is causing the problem but now I can't seem to reproduce it with my custom builds of your test code. What version of network did you use to build the executable?

This cabal file should work, right?

Because when I build it on my Win8.1 machine and send it to my server it runs fine.

It should. The fact that it doesn't repro means the bug could be somewhere other than we initially thought. How did you install GHC on your Win8.1 machine? Are you using 64-bit? Can you test the newest stack Windows binaries- both 32-bit and 64-bit- and confirm that they both still reproduce the problem?

Interestingly, stack-0.1.2.0-i386-windows crashes, stack-0.1.2.0-x86_64-windows works fine.
I've tested it with stack new.

And I'm guessing you were building on your Win8.1 machine with GHC 64-bit?

My 8.1 machine got GHC through HP. So it's 7.8. I downloaded the 64bit version of Haskell Platform.
Both OSes are running 64bit Windows.

This is interesting. Would you be able to download a 32-bit GHC (maybe via MinGHC) and try building the program to confirm that this is a 32-/64-bit difference? This would be valuable to report to the GHC team and/or network library.

In any event, it seems like we have a reliable workaround for this problem, which is very good.

I'll see how much of a hassle that is.
So the i386 variant is the 32bit one, right?

Yes

On Wed, Jul 8, 2015 at 5:34 AM Luka Horvat notifications@github.com wrote:

I'll see how much of a hassle that is.
So the 386 variant is the 32bit one, right?

—
Reply to this email directly or view it on GitHub
#393 (comment)
.

Ok, I did the easiest thing and installed MinGHC 64bit on the server. This previously didn't work when I tried then doing cabal update (that was with the 32bit version). This time it worked.

I'll see if I can install the 32bit version on my 8.1 machine (without it wrecking havoc on my existing setup) and see what happens when I try compiling the code and running it on the server.

So I can't even build the project with 32bit MinGHC (this could be due to 7.10, or due to it being 32bit). I get this error when doing cabal build

That would also explain the crash: linker symbols are missing when using the 32-bit binary. Here's what I recommend:

1. Report this information to the network package
2. We add a note to the download page that 64-bit stack may be necessary on newer Windows releases, referencing this issue.

Pinging @ndmitchell, who may be interested in this issue, and @manny-fp for the release process.

And thank you very much @LukaHorvat for tracking this down!

No problem. Glad I could help.

So if this really is a newer windows version it's quite possibly going to hit lots of people with Win 10 which is very soon now. The symbols should exist on 32bit so I guess something has gone wrong.

Note that @LukaHorvat opened haskell/network#176 about this, for others interested in following up.

It's unlikely that this issue will get fixed anytime soon. network's author is a consistent Windows hater. I've filed an issue on unavoidable Unicode problems when building network under Windows. It was something like 5 years ago, and it's not fixed yet.

The three possible ways to fix the issue are

• Make a PR to network and hope that author will accept it;
• Drop network from stack's dependencies;
• Drop Windows from a list of supported systems.

Didn't read this discussion thoroughly, but please take into attention that Windows Server 2012 may even have no WOW64 installed at all, i.e., no 32-bit program support altogether.

So if this really is a newer windows version it's quite possibly going to hit lots of people with Win 10 which is very soon now. The symbols should exist on 32bit so I guess something has gone wrong.

FWIW, 32-bit stack works fine on Windows 10 64bit (at least on Microsoft's free VM). I just completed stack setup and am currently building stack, so I suspect @awson's right:

Didn't read this discussion thoroughly, but please take into attention that Windows Server 2012 may even have no WOW64 installed at all, i.e., no 32-bit program support altogether.

Googling confirms that. References:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd371790(v=vs.85).aspx
http://sqlanywhere-forum.sap.com/questions/11967/features-removed-or-deprecated-in-windows-server-2012