Continuing this on devel on account of its technicality. See http://lists.wfu.edu/pipermail/gretl-users/2015-December/011399.html for original context. I said I'd look into this more carefully -- see http://lists.wfu.edu/pipermail/gretl-users/2015-December/011414.html Here's what I've found. 1) I can't see anything in the gretl eigensym code that would result in our sending an invalid pointer argument to the underlying double-precision Lapack eigenvalues function dsyev. So this does appear to be an openblas bug (which I believe is specific to 64-bit Windows). 2) There's a commit to openblas git from 11 days ago that looks very relevant (title "Fixed gemv bug for Windows"). See also https://github.com/xianyi/OpenBLAS/issues/697 . This pertains to a quite general BLAS function, dgemv, which is no doubt called by dsyev but may also be called by other specialized Lapack functions on which libgretl depends. So it's important we incorporate the fix. 3) Until today we've packaged a build of openblas 2.14 with our Windows installers. There's a more recent "stable release" (2.15, dated 2015-10-27) but it's not recent enough to include the fix mentioned above. Crashes on Windows have been reported for version 2.15 (see the "issues" link above). 4) At this point, in our Windows builds, we can either use current openblas git (2.16dev) -- which I've already done in the snapshot -- or we could try cherry-picking the gemv/Windows patch from http://matzeri.altervista.org/works/openblas/ and applying it to openblas 2.15. In the latter case we'd obviously have to check that this patch in itself works to eliminate the crash -- that is, there isn't some other crucial difference that I haven't yet identified. Allin