Troubleshooting

This section provides troubleshooting procedures and debugging techniques for Oracle TDE with the DuoKey PKCS#11 provider against Cockpit v2.

Cockpit v2 model

The provider is configured with a pkcs11.toml file (located via the DKE_PKCS11_CONF environment variable) and authenticates with an access_token bearer credential. The access_guid carried in the server_url is a separate, non-secret routing identifier — not the credential. There is no OAuth2 client-credentials flow, no username/password, and no separate tenant or vault field. The HSM partner is Securosys.

Diagnostic Checklist

When troubleshooting TDE issues, follow this systematic approach.

Step 1: Verify the PKCS#11 Library Is Installed Correctly

The library is installed unchanged — keep its shipped name, do not rename it to libpkcs11.so.

# Linux: the library lives here for Oracle Database
ls -la /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so

# Oracle Key Vault (OKV) installs it under the generic HSM directory instead
ls -la /usr/local/okv/hsm/generic/libdke_pkcs11.so

# Verify it is a valid shared object
file /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so

# Check the Cryptoki entry point is exported
nm -D /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so | grep C_GetFunctionList

On Windows the provider is dke_pkcs11.dll.

glibc / OS match

The library must be the build for your OS — do not assume the glibc version from the Oracle release. Confirm the actual host with ldd --version | head -1 before requesting a build; for example, Oracle's own official 19.3.0.0 Enterprise Edition container image runs Oracle Linux 7.9 / glibc 2.17, not OL8. A build against a newer glibc than the host provides will fail to dlopen and, because it never initializes, produces no provider log at all. This is the single most common cause of a failed keystore open — see ORA-28353 below.

Confirmed: this exact mismatch (GLIBC_2.18' not found, skgdllDiscover did not find any library files, ORA-28376: cannot find PKCS11 library) was reproduced live against the official 19.3.0.0 Enterprise Edition image, whose OL7 base only ships glibc up to 2.17. Rebuilding the library against an OL7 baseline (glibc ≤ 2.17) resolved it — glibc is backward-compatible, so the same OL7-built library also covers OL8/OL9 hosts (21c, 23ai and later). There is no need for a separate build per Oracle version; build once against the oldest host you support.

Step 2: Verify the Configuration File and Environment

# As the oracle user, confirm the config path is exported
sudo su - oracle
echo "$DKE_PKCS11_CONF"          # e.g. /etc/dke/pkcs11.toml

# Confirm the file exists and is readable by oracle
ls -la "$DKE_PKCS11_CONF"

# Review the effective settings (server_url, access_token, verify_tls, logging)
cat "$DKE_PKCS11_CONF"

Any field can be overridden with a DKE_PKCS11_* environment variable (see Configuration Reference); if both are set, the environment variable wins.

Step 3: Test the Library Independently

export DKE_PKCS11_CONF=/etc/dke/pkcs11.toml

# List the single virtual slot the library presents
pkcs11-tool --module /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so --list-slots

# List objects (the PIN here is advisory — the real credential is the access_guid)
pkcs11-tool --module /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so -l --pin 1234 --list-objects

Step 4: Check the Oracle Configuration

-- Connect as SYSDBA
sqlplus / as sysdba

-- Check wallet root and TDE configuration
SHOW PARAMETER wallet_root;
SHOW PARAMETER tde_configuration;   -- should reference KEYSTORE_CONFIGURATION=HSM

-- Check keystore status
SELECT CON_ID, WRL_TYPE, STATUS FROM V$ENCRYPTION_WALLET;

The keystore type is HSM. In ADMINISTER KEY MANAGEMENT statements the PIN string (for example "user:1234") is advisory — the credential that actually authorizes the call to the Cockpit is the access_guid in pkcs11.toml.

Step 5: Review the Logs

# DuoKey PKCS#11 provider log (path from logging_folder / DKE_PKCS11_LOGGING_FOLDER)
tail -100 /var/log/dke-pkcs11/*.log

# Oracle alert log
tail -100 $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/alert_$ORACLE_SID.log

# Oracle trace files (if errors occurred)
ls -lt $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/*.trc | head -5

No provider log at all?

If /var/log/dke-pkcs11/ is empty after a failed operation, the library was almost certainly never loaded (wrong path, wrong vendor/version directory, or a glibc-mismatched build). Start with Step 1.

Common Error Scenarios

ORA-28353: failed to open wallet

Symptoms:

ORA-28353: failed to open wallet

Most common root cause — glibc / OS mismatch. The libdke_pkcs11.so build does not match the database host OS, so Oracle's dlopen of the library fails before C_Initialize ever runs. A telltale sign is that there is no entry in /var/log/dke-pkcs11/ — the provider never got far enough to log.

Other causes:

1. The .so is in the wrong vendor/version directory, or is missing entirely.
2. The library was renamed (it must stay libdke_pkcs11.so, not libpkcs11.so).
3. The oracle user cannot read the library or the configuration file.

Debugging steps:

# 1. Confirm the deployed library is in the exact expected directory
ls -la /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so

# 2. Confirm it loads and resolves all dependencies on THIS host
ldd /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so   # look for "not found"

# 3. Confirm the glibc on this host
ldd --version | head -1

# 4. Check the Oracle alert log for the dlopen failure
tail -100 $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/alert_$ORACLE_SID.log | grep -i -E "pkcs11|dlopen|hsm"

Solution: Confirm the libdke_pkcs11.so build present, unchanged, at /opt/oracle/extapi/64/hsm/DuoKey/1.0/ (or /usr/local/okv/hsm/generic/ on OKV) matches this host's glibc — check with ldd --version | head -1, don't assume it from the Oracle version. If you deployed a build for a newer glibc than this host provides, replace it with the correct build for your OS.

403 / invalid access token

Symptoms:

The provider log shows an authentication rejection, and the keystore open or key operation fails:

[ERROR] Cockpit request rejected: 403 Forbidden (invalid access token)

Possible causes:

• The access_guid in pkcs11.toml (access_token, or the DKE_PKCS11_ACCESS_TOKEN override) does not match the access_guid embedded in server_url, or does not match the app in the Cockpit.
• The Oracle TDE app is disabled (or its token was rotated) in the Cockpit.

Debugging steps:

# Confirm access_token matches the access_guid in the server_url
grep -E "server_url|access_token" "$DKE_PKCS11_CONF"

# Confirm the Cockpit API host is reachable (not the frontend hostname —
# a wrong host still returns HTTP 200, just with an HTML page instead of JSON)
curl -I https://<cockpit-api-host>/

Solution: Re-download the app's deployment bundle from Cockpit v2 (it regenerates a matching pkcs11.toml), and confirm the app is enabled in the Cockpit. Do not hand-edit the token.

ORA-00600 [kcbtse_populate_tbskey_1]

Symptoms:

ORA-00600: internal error code, arguments: [kcbtse_populate_tbskey_1], ...

Cause: A non-length-preserving wrap was used on the TDE key path — for example an AES-GCM envelope, which adds an IV and auth tag and changes the ciphertext length. Oracle TDE requires the key-wrapping to be length-preserving, i.e. AES-CBC (with PKCS padding, AES-CBC-PAD). A length-changing wrap corrupts the tablespace-key population and surfaces as this ORA-00600.

Solution: Use a provider build/configuration that wraps the TDE master key with AES-CBC(-PAD) on the TDE path. Re-download the deployment bundle if the app was created with the wrong wrapping mechanism, and re-key once corrected.

ORA-46664: master key not created for all containers

Symptoms:

ORA-46664: master key not created for all PDBs

Typically seen during a CONTAINER=ALL set-key / rekey.

Possible causes:

• One or more PDBs were not OPEN READ WRITE at the time of the rekey.
• The master key was not created for every container.

Debugging steps:

-- Confirm every PDB is OPEN READ WRITE
SELECT con_id, name, open_mode FROM v$pdbs ORDER BY con_id;

-- See which containers already have a key
SELECT con_id, key_id, activation_time FROM v$encryption_keys ORDER BY con_id;

Solution: Open all PDBs READ WRITE, or key each container in its own session — set the key in the root (CDB$ROOT), then in each PDB individually:

-- In the root
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "user:1234" WITH BACKUP CONTAINER=CURRENT;

-- Then, connected into each PDB
ALTER SESSION SET CONTAINER = <pdb_name>;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "user:1234" WITH BACKUP CONTAINER=CURRENT;

ORA-46693 / ORA-28365: library or keystore not open

Symptoms:

ORA-46693: An error occurred while loading library for Transparent Data Encryption
ORA-28365: wallet is not open

Possible causes:

• The PKCS#11 library could not load (see ORA-28353 for the glibc/path checks).
• The HSM keystore is not open in the current container.
• The library reached the Cockpit but the operation failed (connectivity, TLS, or a rejected token).
• The keystore was opened in one sqlplus session and the dependent operation (SET KEY, ALTER TABLESPACE … ENCRYPT) was run in a separate session some time later — Oracle's default HSM connection heartbeat can close the keystore in between, even though SET KEYSTORE OPEN reported success moments earlier.

Debugging steps:

-- Is the keystore open in this container?
SELECT CON_ID, WRL_TYPE, STATUS FROM V$ENCRYPTION_WALLET;

# Provider log detail for the failed operation
tail -200 /var/log/dke-pkcs11/*.log

Solution: Confirm the library loads (Step 1), open the HSM keystore, and confirm connectivity to the Cockpit (below). If the keystore reported OPEN moments earlier, re-run SET KEYSTORE OPEN immediately before the dependent statement in the same script/session, or widen _heartbeat_period_multiplier (see Best Practices).

Instance crash (ORA-03113) after ORA-28407 in a background process

Symptoms:

The alert log shows kzthsmcc encountered: ORA-28407 ... HSM heartbeat check failed to cache object handle, HSM connection lost, closing wallet, and eventually a background process (commonly DBW0) terminates the instance, surfacing as ORA-03113: end-of-file on communication channel to any connected client.

Cause: DKE_PKCS11_CONF was not visible to the environment the instance itself was started with — for example the database was started from a context that never sourced the Oracle OS user's shell profile (a bare docker exec, a non-login ssh command, or a service manager that doesn't inherit .bash_profile). A client session that separately exports the variable can still open the keystore manually, masking the problem — but Oracle's background HSM heartbeat check runs against the instance's environment and fails silently until it eventually kills a background process.

Solution: Persist DKE_PKCS11_CONF in /home/oracle/.bash_profile (or .profile) as described in Getting Started, and always start/restart the database from a login shell that sources it. After a crash, restart the host/instance, confirm the variable is set for a fresh sudo su - oracle session, then re-run STARTUP from that session.

ORA-28374: typed master key not found in wallet

Symptoms:

ORA-28374: typed master key not found in wallet

Possible causes:

• The keystore is closed.
• No master key has been created in this container yet.

Solutions:

-- If the keystore is closed, reopen it (PIN is advisory; the access_guid authorizes)
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
  IDENTIFIED BY "user:1234"
  CONTAINER=ALL;

-- If no key exists, create the master key
ADMINISTER KEY MANAGEMENT SET KEY
  IDENTIFIED BY "user:1234"
  WITH BACKUP
  CONTAINER=ALL;

Connectivity and TLS Troubleshooting

Every Cryptoki operation is an HTTPS call to the server_url in pkcs11.toml. If the Cockpit host is unreachable, or verify_tls = true and the server certificate cannot be validated, keystore and key operations fail.

Test reachability to the Cockpit:

# Basic HTTPS reachability
curl -I https://<cockpit-host>/

# TCP reachability on 443
nc -zv <cockpit-host> 443

Verify the TLS certificate:

# Inspect the certificate the Cockpit presents
openssl s_client -connect <cockpit-host>:443 -showcerts </dev/null

• If the Cockpit uses a certificate your host does not trust, add the CA to the host trust store rather than disabling verification.
• verify_tls = false (or DKE_PKCS11_VERIFY_TLS=false) is for testing against self-signed certificates only — keep it true in production.

Then check the provider log at /var/log/dke-pkcs11/ for the specific connection or handshake error, and raise logging_level to debug during setup:

grep -i -E "connect|handshake|timeout|tls|certificate" /var/log/dke-pkcs11/*.log

Provider Log Analysis

The DuoKey PKCS#11 provider writes to the directory in logging_folder (default referenced as /var/log/dke-pkcs11/). Raise logging_level to debug while troubleshooting, then lower it again.

Key things to look for:

• Initialization — the provider read pkcs11.toml, resolved server_url, and completed its readiness probe against the Cockpit.
• Authentication — the access_token bearer credential was accepted (a 403 here points to the 403 / invalid access token scenario above).
• Key operations — generate / encrypt / decrypt calls and their result codes.
• Connection errors — DNS, TCP, timeout, or TLS handshake failures point to the Connectivity and TLS section.

If the log directory is empty after a failure, the library was never loaded — return to the ORA-28353 / Step 1 checks.

Oracle Alert Log Analysis

Oracle's alert log records TDE-related messages that help diagnose provider issues.

Successful load and open:

TDE: Loading PKCS#11 library: /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so
TDE: PKCS#11 library loaded successfully
TDE: HSM keystore opened successfully

Library load failure (glibc / path):

TDE: Failed to load PKCS#11 library: /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so
TDE: Error: dlopen() failed: cannot open shared object file

Solution: Check the library path and confirm the deployed build's glibc matches this host's — ldd --version | head -1, don't assume from the Oracle version (see ORA-28353).

TDE: PKCS#11 function C_Initialize failed: CKR_DEVICE_ERROR

Solution: Check the provider log, verify connectivity to the Cockpit, and confirm the access_guid.

Configuration Reference

The full pkcs11.toml schema, every field, and all DKE_PKCS11_* environment-variable overrides are documented once, authoritatively, in PKCS#11 Provider Configuration (pkcs11.toml) — don't duplicate it here when debugging; open that page side by side with the file you're troubleshooting.

Useful SQL Queries for Debugging

Check keystore status:

SELECT CON_ID, WRL_TYPE, STATUS, WALLET_TYPE
FROM V$ENCRYPTION_WALLET
ORDER BY CON_ID;

List all encryption keys:

SELECT
  CON_ID,
  KEY_ID,
  TAG,
  ACTIVATION_TIME,
  CREATOR
FROM V$ENCRYPTION_KEYS
ORDER BY CON_ID, ACTIVATION_TIME DESC;

List encrypted columns:

SELECT
  OWNER,
  TABLE_NAME,
  COLUMN_NAME,
  ENCRYPTION_ALG,
  SALT,
  INTEGRITY_ALG
FROM DBA_ENCRYPTED_COLUMNS
ORDER BY OWNER, TABLE_NAME, COLUMN_NAME;

List encrypted tablespaces:

SELECT
  tablespace_name,
  encrypted,
  encryptionalg
FROM dba_tablespaces
WHERE encrypted = 'YES'
ORDER BY tablespace_name;

Check TDE parameters:

SHOW PARAMETER wallet_root;
SHOW PARAMETER tde_configuration;
SHOW PARAMETER encrypt;

View wallet location:

SELECT * FROM V$WALLET;

Check which PDBs have encryption keys:

SELECT
  p.con_id,
  p.name AS pdb_name,
  ek.key_id,
  ek.activation_time
FROM v$pdbs p
LEFT JOIN v$encryption_keys ek ON p.con_id = ek.con_id
ORDER BY p.con_id;

Linux Deployment Notes

Linux is verified end-to-end, including against Oracle's own official Enterprise Edition container image — not just the XE editions. SET KEYSTORE OPEN (CONTAINER=ALL), SET KEY at both the CDB root and a PDB, and a real CREATE TABLESPACE ... ENCRYPTION round trip (insert, select) all succeeded against Oracle 19.3.0.0 Enterprise Edition (Oracle Linux 7.9). The one real defect this validation surfaced was the glibc/OS mismatch above — the reproducible build previously targeted Oracle Linux 8 (glibc 2.28), which the official 19.3.0.0 image's actual OL7 base (glibc 2.17) cannot load. Building against the oldest supported host (OL7) fixed it and is now the default; the same build also covers newer hosts, so no separate build per Oracle version is needed.

Two operational details worth knowing if you script this yourself: WALLET_ROOT is SPFILE-scoped and needs a full instance bounce to take effect (no way around this — it's an Oracle requirement, not a DuoKey one); and the keystore-open/SET KEY sequence should run in one session end to end — the PKCS#11 login state is per-process, so if you split the flow across separate connections, a fresh connection made after the keystore is already open (from Oracle's perspective) does not automatically re-authenticate to the HSM in that new session's own process.

Oracle 12.2 base release (12.2.0.1.0): use sqlnet.ora, not WALLET_ROOT

WALLET_ROOT and the TDE_CONFIGURATION instance parameter do not exist in the base 12.2.0.1.0 release (ALTER SYSTEM SET on either raises ORA-02065: illegal option for ALTER SYSTEM — confirmed absent from v$parameter). They were added in a later 12.2 Release Update / 18c+, not the GA release. Verified end-to-end on genuine Oracle Database 12.2.0.1.0 Enterprise Edition (built from real installer media, not a community image) using the pre-WALLET_ROOT mechanism instead — add to sqlnet.ora (alongside the network/admin directory, or wherever your TNS_ADMIN points):

ENCRYPTION_WALLET_LOCATION =
  (SOURCE =
    (METHOD = HSM)
  )

Then the modern (12c+) ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN / SET KEY grammar works exactly as documented elsewhere on this page — no instance bounce needed for this step, unlike WALLET_ROOT. If you're unsure which mechanism your target release needs, check v$parameter for wallet_root first — if it's absent, use sqlnet.ora.

Oracle 12.1.0.2: confirmed the fixed extapi path, and a different CREATE TABLESPACE grammar

Verified end-to-end on genuine Oracle Database 12.1.0.2 Enterprise Edition (Oracle's own official container image). Two things worth knowing:

• This is the test that actually proved the /opt/oracle/extapi/... path is fixed, not $ORACLE_BASE-relative. This image's real ORACLE_BASE is /u01/app/oracle; the library was not found there and had to be placed at the literal /opt/oracle/extapi/64/hsm/DuoKey/1.0/ path instead — see the callout in Getting Started. 12.1 also predates WALLET_ROOT, so it needs the same sqlnet.ora ENCRYPTION_WALLET_LOCATION mechanism as 12.2.0.1.0 above.
• CREATE TABLESPACE ... ENCRYPTION uses an older grammar in 12.1: the trailing ENCRYPT keyword (ENCRYPTION USING 'AES256' ENCRYPT) used on 12.2+/18c+/19c+ raises ORA-02180: invalid option for CREATE TABLESPACE on 12.1. Use ENCRYPTION USING 'AES256' DEFAULT STORAGE(ENCRYPT) instead.

Oracle 11g R2's unpatched ORA-28376 gate is confirmed cross-platform, not a Windows-specific quirk. Retested against gvenzl/oracle-xe:11-slim (Oracle Database 11g Express Edition Release 11.2.0.2.0) on Linux, with the library correctly staged and readable (ruling out the usual path/permission/glibc causes): ALTER SYSTEM SET ENCRYPTION WALLET OPEN and ALTER SYSTEM SET ENCRYPTION KEY both fail with ORA-28376: cannot find PKCS11 library, and — same signature as the Windows finding — there is no kzthsminit/HSM TRACING entry anywhere in the session's trace files, meaning Oracle never even attempts the PKCS#11 discovery step pre-patch. This is table-stakes Oracle kernel behavior, unrelated to OS. Note that Oracle XE editions cannot be individually patched (no opatch support), so this gate cannot be lifted on XE at all — a patched 11.2.0.4 Enterprise/Standard Edition install would be needed to actually test the HSM path on 11g R2.

Windows Deployment Notes

Windows is verified end-to-end. SET KEYSTORE OPEN, SET KEY, and a real CREATE TABLESPACE ... ENCRYPTION round trip (insert, select, confirmed inaccessible with the keystore closed — ORA-28365) all succeeded against Oracle 21.3.0.0.0 Enterprise Edition for Windows, over a real network connection to Cockpit v2. See Getting Started on Windows for the full walkthrough. The reference table below covers everything that can go wrong and how to tell them apart — most of it produces the same generic-looking ORA-28353/ORA-28407, so the diagnostic signal (which log has detail, what a curl returns) matters more than the error code itself.

Symptom	Cause	Fix
ORA-28353/ORA-28407, empty provider log, PKCS#11 error code 5 in the session's own trace file	pkcs11.toml unreadable by the Oracle service account	Grant NT SERVICE\OracleService<SID> explicit access: icacls <path> /grant "NT SERVICE\OracleService<SID>:(F)". Confirm the exact account with Get-WmiObject Win32_Service -Filter "Name='OracleService<SID>'" | Select StartName — don't assume an existing ACL entry from another Oracle Home is the right one.
curl/Invoke-WebRequest against server_url returns HTTP 200 with an HTML page, not JSON	server_url points at the frontend hostname, not the API one	Use the API-serving hostname (e.g. cockpit-api-<env>.duokey.cloud), not the browser UI one.
ORA-28353, library never found, skgdllDiscover did not find any library files	Library deployed under %ORACLE_HOME%\extapi\ or %ORACLE_BASE%\extapi\	Deploy to the fixed path C:\oracle\extapi\64\hsm\DuoKey\1.0\dke_pkcs11.dll instead — confirmed independent of where the database software or ORACLE_BASE actually live.
DLL fails to load, Win32 error 126	Dynamically-linked CRT (VCRUNTIME140.dll, api-ms-win-crt-*) not present on the host	Build with RUSTFLAGS="-C target-feature=+crt-static" cargo build --release -p dke-pkcs11; verify with dumpbin /DEPENDENTS dke_pkcs11.dll.
ORA-07445 [kzthsminit_discover_load_pkcs_lib] or [kzthsminit_load_pkcs_lib], instance crash	A real, rare, non-deterministic Oracle-side defect — see below	Retry. Does not indicate a configuration problem.
ORA-28353/crash right after ALTER SYSTEM SET TDE_CONFIGURATION=HSM, more than one file under the vendor/version directory	Oracle's directory-discovery scan mishandles multiple candidates	Keep exactly one file per <vendor>\<version> directory.
ORA-28376: cannot find PKCS11 library on Oracle 11g R2	Unpatched 11.2.0.x — Oracle never attempts to load the library at all. Confirmed cross-platform (Windows and Linux), not a Windows-specific issue — see Linux Deployment Notes.	Apply patch 18948524 (or newer). Not needed on 18c+. Not possible on Oracle XE (no individual patching) — a patched Enterprise/Standard Edition install is required to use the HSM path on 11g R2.

Oracle 11g R2 on Windows: LocalSystem service account, sqlnet.ora not WALLET_ROOT

Confirmed against a genuine 11.2.0.1.0 Enterprise Edition install (real installer media, INSTALL_DB_AND_CONFIG silent install). Two differences from the later versions documented on this page:

• The Windows service (OracleService<SID>) runs as LocalSystem on 11g R2, not the per-service virtual account (NT SERVICE\OracleService<SID>) used from later releases onward. LocalSystem already has full access to the filesystem, so the icacls/permissions issue above does not apply here — if you hit ORA-28376 on 11g R2 with the library correctly staged, it is the unpatched-instance gate, not a permissions problem.
• 11g R2 predates WALLET_ROOT (introduced in 12.2), so it needs the same pre-WALLET_ROOT sqlnet.ora ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)) mechanism as 12.1/12.2.0.1.0 on Linux — added to %ORACLE_HOME%\network\admin\sqlnet.ora (or wherever TNS_ADMIN points).

Confirmed Oracle-side defect: ORA-07445 in kzthsminit_discover_load_pkcs_lib/kzthsminit_load_pkcs_lib, reproduced on every Windows release tested (19.0.0.0, 19.3.0.0.0, 21.3.0.0.0), all unpatched GA media. The full incident trace shows Oracle's own code crashing on an indirect call through a corrupted register (Rsi/Rbx holding an obviously invalid, non-canonical pointer) — while the correct address for C_GetFunctionList is visible elsewhere on the same stack, meaning Oracle resolved the right symbol and then jumped through the wrong register. This is entirely internal to Oracle's calling code; it has nothing to do with what the loaded library implements. It reproduced identically against this provider's library, a third-party OpenSC module, and a genuine Securosys Primus binary — ruling out CRT linking strategy, implementation language, and vendor identity as explanations.

Also seen on Linux, in a different kernel function entirely. Against Oracle 12.1.0.2 Enterprise Edition, ORA-07445: exception encountered: core dump [kzekmsmk()+14198] [SIGILL] [Illegal operand] crashed the instance during the HSM "heartbeat" liveness check (kzthsmcc, immediately after ORA-28407 ... CKR_GENERAL_ERROR on the heartbeat's object-handle cache) — right after a SET KEY had already completed and genuinely rotated the master key. Same class of defect (illegal-instruction crash inside Oracle's own HSM-interaction kernel code, non-deterministic, unrelated to the library), just a different entry point (kzekmsmk vs kzthsminit_*) and a different platform. This further confirms it's a broad characteristic of Oracle's PKCS#11 kernel integration across releases and platforms, not a single localized bug.

It is non-deterministic and does not block a working deployment. The exact same configuration that crashed repeatedly later completed normally with no code change on either side — the signature of a bug reading an uninitialized register, not a deterministic defect tied to a specific library or build. A full end-to-end TDE deployment succeeded on the same unpatched 21.3.0.0.0 GA media without ever needing a Release Update or My Oracle Support access. If you hit this exact ORA-07445 signature, retry — it is very unlikely to indicate a configuration problem on your end.

Also confirmed: Azure AD–joined Windows hosts hit an unrelated Oracle installer bug (not a TDE issue) — the classic OUI and the XE MSI/InstallShield wrapper call a legacy Win32 API to enumerate local group memberships, which fails against a cloud-only account regardless of elevation mechanism (runas, Start-Process -Credential, schtasks). The only workaround is a genuine local Windows administrator account with a real interactive logon. Separately, DBCA's create/start-instance step can look hung for several minutes on a loaded or antivirus-scanned host without actually being stuck — check DBCA_PROGRESS in <ORACLE_BASE>/cfgtoollogs/dbca/<SID>/<SID>.log before killing it.

Historical: Windows Cryptoki struct packing (fixed). The Cryptoki reference header requires #pragma pack(1) on Windows but natural alignment on Unix. dke-pkcs11 originally only implemented the Unix layout — a real, silent ABI bug that shifted every struct field after the first multi-byte-aligned one, so a Windows caller reading CK_FUNCTION_LIST saw garbage function pointers. Fixed in the provider (every struct is now conditionally packed per platform); only affects builds predating that fix.

Getting Help

If you're still experiencing issues after following this troubleshooting guide:

1. Check the DuoKey Support Portal: https://support.duokey.cloud
2. Provide the provider log: relevant excerpts from /var/log/dke-pkcs11/
3. Provide the Oracle alert log: relevant TDE error messages
4. Document your configuration: share pkcs11.toml without the access_guid (redact server_url and access_token)
5. Confirm the library build: note the host's actual OS/glibc (ldd --version) and the libdke_pkcs11.so you deployed

Next Steps

• Operations → - Learn operational procedures
• Architecture Documentation - Understand system architecture