Error 0xc0000142

[Olly Betts]

On Tue, Oct 15, 2024 at 01:37:01PM +0100, Wookey wrote:
> OK. Installing survex and checking that it broke as expected was
> fairly easy (although there were an awful lot of 'this is not a
> trusted executable/supplier' warnings to ignore).

I don't think there's a good way to avoid that without getting sucked
into paying a fairly hefty (and recurring) amount for a code signing
certificate, unless perhaps someone's already set up for such signing
and willing to take on the job.

> I found that cavern --help and survexport --help both worked. Only
> aven gives the expected error.

Hmm, that matches what Mike McCombe said but Graham Mullan said:

| it was only cavern that ran. The other three gave the Windows error
| box "The application was unable to start correctly (0xc0000142) Click
| OK to close the application. 

> Here is the log from loading aven.exe, then doing 'g' to run it until
> there is an error or breakpoint. It may provide some clues. It seems
> to be dying in the system library C:\Windows\SYSTEM32\NTASN1.dll
> 
> And here are screenshots of the 'threads' and 'stack' windows which
> may also give clues as to where it is blowing up:
> http://wookware.org/files/threads.png
> http://wookware.org/files/stack.png
> 
> A Null pointer return address in LdrInitializeThunk seems a bit
> suspicious too, but maybe that's how a new windows process starts.

That seems most likely to me.

> In which case the OpenSSlInit looks like where things start to go wrong.

The C++ symbol decodes as OpenSSLInit::OpenSSLInit() and it's throwing
an exception, but libpodofo's source code doesn't seem to contain a
class called OpenSSLInit.  It's not just something inlined from
OpenSSL's headers either.  The address from the backtrace is definitely
in the range where libpodofo is listed as loaded:

> ModLoad: 00007ffc`56830000 00007ffc`56b9e000   C:\Program Files\Survex\libpodofo.dll

Can you get the debugger to print the exception?

> This is on Windows 10. The version of survex I was offered for
> 'windows' called itself 'win32' so I presume is actually the 32-bit
> version?

It's actually 64-bit - the "win32" is just hard-coded and I didn't spot
it when I switch to a 64-bit build.  I'll rename.

One thing that is really curious is that apparently 1.4.9 works OK but
that also contains the change which seemed mostly likely the cause.

Perhaps the problem is actually in one of the dependencies in which case
it is quite likely to have been fixed in the two months since 1.4.11.

Could you try with:

https://github.com/ojwb/survex/actions/runs/11357260545/artifacts/2061147094

This should give you a .zip file containing an installer for a commit I
pushed today.

Cheers,
    Olly