Python applications fail to start when SSLKEYLOGFILE points to Avast’s aswMonFltProxy device

Avast Free Antivirus / Premium Security
1

Python applications on my Windows machine can terminate during startup when they inherit an SSLKEYLOGFILE value pointing to Avast’s aswMonFltProxy device. Removing this variable inside the affected Python process makes SSL initialization succeed, without disabling Avast.

This affected Serena, a Python-based MCP server used by Codex and ZCode. When Serena fails to start, its tools remain unavailable, interrupting work and requiring troubleshooting. The underlying crash can be reproduced without either application, without an API key, and without making a network request.

Minimal reproduction

Use the affected Python interpreter in an environment where SSLKEYLOGFILE already points to:

\\.\aswMonFltProxy\<device-id>

Run:

python -c "import ssl; ssl.create_default_context(); print('OK')"

Observed result: the process exits with code 1:

OPENSSL_Uplink(<address>,08): no OPENSSL_Applink

Then repeat with the same interpreter, removing the variable only inside the test process:

python -c "import os; os.environ.pop('SSLKEYLOGFILE', None); import ssl; ssl.create_default_context(); print('OK')"

This succeeds and prints OK.

Environment

  • Avast Free Antivirus 26.7.11086.3745

  • Windows 11, build 26200, x64

  • Python 3.13.13, AMD64, installed through uv

  • OpenSSL 3.5.5

  • Serena 1.7.0

  • Reproduced on 11 September 2026

Workaround and request

A local launcher now removes SSLKEYLOGFILE before importing Serena. With this launcher, a connection test retrieved all 23 Serena tools and successfully called one. Avast remained enabled.

This confirms the SSL initialization failure and the workaround on this machine; it does not establish that every Codex or ZCode startup problem has the same cause.

Could Avast investigate this compatibility problem and provide a supported fix? Is this device-path value intended to be inherited by Python processes?

No TLS keys, credentials, or memory dumps are included.

2

The issue stopped reproducing after updating the Python build from 3.13 to 3.15. The check was performed with the SSL KEY LOG FILE variable saved, which was set by Avast. The cause turned out to be an error in the previous Python/OpenSSL build, so there is no reason yet to consider this an Avast error.