Access Violation shows OpenSSL stack

[Dipak B]

Dear community,

Can you please share insights on the following?

Background:

A Windows service periodically loads and unloads a DLL statically linked to Openssl 3.4.0.

This service has the DLL loaded always but when new version of DLL arrives, it unloads the older DLL and loads the new DLL while maintaining its PID as same. Thus service does not stop.

This DLL file calls SSL_Library_Init() once in single threaded manner as part of initialization. Later many others threads exercise Openssl.

Now everytime the host Windows service unloads my DLL using FreeLibrary() (after taking due care) and loads newer version of my DLL there is a access violation on 1st thread of my DLL

This access violation shows Openssl frames in the stack trace.

Please note that Windows service  has threads that call my DLL and these threads do TLS communication. Some of these Windows service threads outlive the DLL loading and unloading.

On side note, these outliving threads leak since there is no possibility of call to OpenSSL_Stop_Thread() (DLL does not get thread detach notification)

Will dropping explicit call to SSL_Library_Init() help here in fixing access violations? Since this is OpenSSL 3.4.0 this call is not required but it is retained here since long time.

What are the important points that I should be focused on while using DLL which is statically linked to Openssl 3.4.0 in above scenario?

Are these outliving DLL threads some how cause access Violation?

Looking forward to your inputs.

Regards.

[Viktor Dukhovni]

On Sun, Jul 13, 2025 at 08:16:43AM +0530, Dipak B wrote:

> A Windows service periodically loads and unloads a DLL statically linked to
> Openssl 3.4.0.

Your application is quite likely to crash if any threads using the DLL
are still alive at the time of the unload. You MUST ensure that no
threads are using the DLL when it is being unloaded.

--
Viktor.

[Dipak B]

--

DLL gets unloaded from the Windows service after making sure that Threads (of Windows service) that outlive this DLL are not actively executing functions exported by the DLL.

In other words, app makes sure that Windows service threads have finished executing functions exported by DLL and they get returned to custom pool where they wait for other work.

Regards.

[Viktor Dukhovni]

On Sun, Jul 13, 2025 at 04:58:52PM +0530, Dipak B wrote:

> DLL gets unloaded from the Windows service after making sure that Threads
> (of Windows service) that outlive this DLL are not actively executing
> functions exported by the DLL.

That's not enough, they must never again try to execute any OpenSSL
functions, or retain and use any objects returned by the unloaded
library.

> In other words, app makes sure that Windows service threads have finished
> executing functions exported by DLL and they get returned to custom pool
> where they wait for other work.

That's not sufficient, if they retain any references to OpenSSL objects,
this includes OpenSSL-specific thread-specific storage, which is not
easily reinitialised, so bottom line those threads MUST not be returned
to the thread pool, they need to terminate before OpenSSL is unloaded.

--
Viktor.