open https://gitlab.synchro.net/main/sbbs/-/issues/882

100% reproducible, just running this one line of JS: `CryptKeyset(system.temp_dir + "tmpkeyset", CryptKeyset.KEYOPT.CREATE)`

Backtrace:
```

cl32.dll!sFileOpen(ST * stream, const char * fileName, const int mode) Line 5690 C

cl32.dll!openKeysetStream(ST * stream, const char * name, const int nameLength, const CRYPT_KEYOPT_TYPE options, int * isReadOnly, KEYSET_SUBTYPE * keysetSubType) Line 696 C
cl32.dll!openKeyset(int * iCryptKeyset, const int iCryptOwner, const CRYPT_KEYSET_TYPE keysetType, const char * name, const int nameLength, const CRYPT_KEYOPT_TYPE options, KI * * keysetInfoPtrPtr) Line 1626 C
cl32.dll!createKeyset(MESSAGE_CREATEOBJECT_INFO * createInfo, const void * auxDataPtr, const int auxValue) Line 1830 C
[Inline Frame] cl32.dll!createObject(DI *) Line 758 C
cl32.dll!deviceMessageFunction(void * objectInfoPtr, const MESSAGE_TYPE message, void * messageDataPtr, const int messageValue) Line 1102 C
cl32.dll!dispatchMessage(const int localObjectHandle, const MESSAGE_QUEUE_DATA * messageQueueData, OBJECT_INFO * objectInfoPtr, const void * aclPtr) Line 1720 C
cl32.dll!krnlSendMessage(const int objectHandle, const MESSAGE_TYPE message, void * messageDataPtr, const int messageValue) Line 2111 C
cl32.dll!cmdCreateObject(COMMAND_INFO * cmd) Line 254 C
cl32.dll!cryptKeysetOpen(int * keyset, const int cryptUser, const CRYPT_KEYSET_TYPE keysetType, const char * name, const CRYPT_KEYOPT_TYPE options) Line 2313 C
sbbs.dll!js_cryptkeyset_constructor(JSContext * cx, unsigned int argc, unsigned __int64 * arglist) Line 479 C
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for mozjs185-1.0.dll]

```
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6690

What's the value of system.temp_dir when this crashes?

Does changing it to system.temp_dir + "tmpkeyset.ext" make it not crash?
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6691

`system.temp_dir` is "s:\sbbs\node1\temp\"

Changing to "tmpkeyset.ext", still crashes.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6691

`system.temp_dir` is 's:\sbbs\node1\temp\'

Changing to "tmpkeyset.ext", still crashes.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6691

`system.temp_dir` is 's:\sbbs\node1\temp\' <- with trailing slash that gitlab doesn't want to display

Changing to "tmpkeyset.ext", still crashes.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6692

Loading cl32.dll into debugger and caught exception:

fileName appears uninitialized:

```
aclInfo Error reading register value.
dwAttrs Variable is optimized away and not available.
+ fileName 0xcccccccc <Error reading characters of string.> const char *
fSuccess Variable is optimized away and not available.
hFile Variable is optimized away and not available.
length Variable is optimized away and not available.
length Variable is optimized away and not available.
mode 0x0000001e const int
openMode Variable is optimized away and not available.
status Variable is optimized away and not available.
+ stream 0x0a22b7f0 {type=STREAM_TYPE_FILE (0x00000003) flags={flagValue=0x00000000 flagCheckValue=0xffffffff } ...} ST *
type Variable is optimized away and not available.
uErrorMode Variable is optimized away and not available.
```

though nameBuffer appears fine in openKeysetStream().
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6693

sFileOpen() seems to be corrupting the fileNamePtr/fileName pointer.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6694

crashes jsexec too, so good, that'll be easier to use to debug this
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6695

Yeah, debug build of cl32.dll crashes too, that'll be helpful.
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6696

Debug-build crash callstack:
```
ntdll.dll!_strlen() Unknown
ntdll.dll!_RtlInitAnsiStringEx@8() Unknown
KernelBase.dll!Basep8BitStringToDynamicUnicodeString() Unknown

KernelBase.dll!_CreateFileA@28() Unknown

cl32.dll!6d68216d() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for cl32.dll]
[External Code]
```
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6697

Doesn't appear to crash in a debug build of cl32.dll :-(
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6698

Hrm, but it does crash in a new non-debug cl32.dll build (ie: it's not just a bad build)?
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6699

Oh wait, isn't 0xCC the fill pattern of malloc() for the debug CRTL on Windows? --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6700

or 0xCD
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/882#note_6701

It's crashing in release builds, even clean rebuilds
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

close https://gitlab.synchro.net/main/sbbs/-/issues/882
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)