Share via

Smart Card 'cmck certify' test fails

Darth Tester 40 Reputation points
2026-02-09T12:34:39.94+00:00

Dear team,

I try to certify a Smart Card minidriver but I get this output:

C:\SmartCardMinidriverTest> .\cmck.exe certify

Device string in use: $LogFile:encoding=UNICODE,Writemode=overwrite,Shared=false,file="CMCK_log.xml",CRC=true;$Console

WTTLogger_CPP_GitEnlistment(SSCPBLD02); Version: 2.7.3483.0

Loaded minidriver: MyCard_CMx64.dll

Checking if version 4 is supported.... NO.

Checking if version 5 is supported.... NO.

Checking if version 6 is supported.... NO.

Checking if version 7 is supported.... NO.

The minidriver certification is not complete yet! You ran certification tests only for minidriver version 0. However, your minidriver may also support other versions. Please run 'cmck certify' to complete all required tests to get fullly certified.

No CMCK_log.xml file is generated.

I set up test environment as previous times, but now test fails.

Any idea?

Thanks in advance.

Windows for business | Windows Client for IT Pros | Devices and deployment | Other
0 comments No comments
{count} votes

Answer accepted by question author
  1. VPHAN 25,000 Reputation points Independent Advisor
    2026-02-22T06:52:18.7333333+00:00

    Hello Darth Tester,

    In our previous exchanges, I directed your focus toward unhandled exceptions within the CardAcquireContext function and potential mismatches in the Smart Card Resource Manager ATR registry mappings under HKLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards. Reevaluating this guidance against your recent certutil output and your Windows 11 environment, the root cause is highly likely an initialization failure within the CARD_DATA structure or a strict Windows 11 security policy blocking execution, rather than just a simple registry mismatch. The "smart card cannot perform the requested operation" error directly corresponds to SCARD_E_UNSUPPORTED_FEATURE. This confirms the SCRM cannot validate the driver's capabilities because the function signature or return data is invalid according to the Smart Card Minidriver Specification, causing the tool to fall back to version 0 and exit before the WTT logging subsystem flushes the buffer to disk.

    To resolve this issue, you must inspect your CardAcquireContext implementation and guarantee that it explicitly assigns pCardData->dwVersion to a supported integer, such as 7 for v7.07, and assigns all required function pointers before returning ERROR_SUCCESS. Furthermore, running the HLK on modern Windows 11 builds enforces strict Hypervisor-Protected Code Integrity (HVCI) requirements. If your MyCard_CMx64.dll attempts to load unsigned dependencies or allocates executable memory improperly, the OS will silently block the operations. This causes cmck.exe to fail the version check and terminate abruptly. You must compile your minidriver with the /INTEGRITYCHECK linker flag and ensure it passes Driver Verifier. I recommend attaching WinDbg to the cmck.exe process and setting a breakpoint directly on your CardAcquireContext export to observe the exact state of the pCardData structure in memory before the function returns or the process terminates.

    Hope this answer brought you some useful information. If it has, please consider accepting the answer so that other people sharing the same issue would benefit too. Thank you :)

    VP


3 additional answers

Sort by: Most helpful
  1. VPHAN 25,000 Reputation points Independent Advisor
    2026-02-13T13:23:27.7166667+00:00

    Hi Darth Tester,

    The message you saw (the smart card cannot ...) means the Smart Card Resource Manager (SCRM) is either failing to map your card's Answer To Reset (ATR) to the correct cryptographic provider, or your minidriver is throwing an unhandled exception during initialization. Because cmck.exe successfully loads MyCard_CMx64.dll into memory but fails all version checks and abruptly exits without flushing the CMCK_log.xml buffer, your minidriver is highly likely encountering an access violation or stack corruption inside the CardAcquireContext function. When an unhandled exception terminates the test harness process, the WTT logging subsystem is destroyed before it can commit its buffer to disk.

    Your description requires further technical detail regarding your registry configuration and debugging environment to pinpoint the exact root cause. Please provide the exact ATR string of your test card and verify that it is correctly registered under the HKLM\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards registry hive, specifically ensuring the Crypto Provider and 80000001 registry values accurately point to your minidriver DLL. To capture the precise point of failure preventing the log generation, you must run cmck.exe certify under a user-mode debugger like WinDbg. Attach WinDbg to the command prompt process, execute the certification tool, and examine the call stack when the first-chance exception occurs within your DLL. Additionally, ensure your driver INF file correctly implements the updated directives specified in the Smart Card Minidriver Specification v7.07 for modern Windows 11 environments, as legacy INF registrations often cause the SCRM to reject the context acquisition. Look forward to your data soon.

    VP


  2. VPHAN 25,000 Reputation points Independent Advisor
    2026-02-10T18:20:16.77+00:00

    Hello again Darth Tester,

    Just following up. The failure to generate the log file despite Writemode=overwrite indicates the WTT logging subsystem failed to initialize or the process crashed before flushing the buffer, which often occurs when there is an architecture mismatch. Since your log shows Loaded minidriver: MyCard_CMx64.dll, you must strictly ensure you are running the 64-bit version of cmck.exe from the x64 directory of the Windows Driver Kit (WDK); executing a 32-bit test harness against a 64-bit minidriver (or vice versa) will successfully load the DLL image but fail to map the entry points, resulting in the "NO" output for all version checks.

    Your description is currently insufficient to identify the root cause because it lacks details on the specific WDK version and Windows build, which is critical given that WTT logging dependencies change across OS releases. Please provide the output of certutil -scinfo to confirm the Smart Card Resource Manager (SCRM) can successfully authenticate the card and that no exclusive lock is held by another process. If certutil fails, the issue is with the reader driver or card state; if it succeeds, the issue is isolated to the cmck.exe binary compatibility or file system permissions.

    To address the immediate "no log" error and verify the environment, execute the command from an elevated Administrator command prompt to rule out User Account Control (UAC) virtualization blocking writes to C:\SmartCardMinidriverTest. If the architecture matches and permissions are correct but the error persists, you may be using a deprecated version of the test tool incompatible with the current Smart Card Minidriver Specification v7.07, requiring a WDK update.

    VP


  3. VPHAN 25,000 Reputation points Independent Advisor
    2026-02-09T13:06:33.16+00:00

    Hello Darth Tester,

    To resolve the versioning error, you must ensure your minidriver's CardAcquireContext entry point correctly handles the version negotiation logic as defined in the Smart Card Minidriver Specification. The tool iterates through version levels to check for the implementation of modern features like PIN complexity, ECC support, and read-only card support. You should verify that your code explicitly supports CARD_DATA_CURRENT_VERSION and doesn't return ERROR_REVISION_MISMATCH prematurely for versions 4, 5, 6, or 7 unless they are truly unimplemented. Regarding the missing log file, check the Writemode=overwrite parameter in your device string, if the process is terminated or crashes during the version check loop, the file handle may remain locked or the buffer may not commit to the filesystem. I recommend running the command prompt with elevated privileges and explicitly setting the log path to a known-writable directory like %TEMP% to verify if the issue is strictly a file I/O permission error.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VP

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.