Troubleshooting CTBadSupportFileException in Adobe PDF Library

Overview

An Adobe PDF Library (APDFL) application running in a debugger may produce a message such as:

```text
Microsoft C++ exception: CTBadSupportFileException at memory location ...
```

Historical support cases associate this message with font-resource lookup and configuration. A nonexistent font-resource directory was identified in one case involving application instability. In another case, changing the method used to select a system font prevented a shutdown hang.

The message alone does not establish the cause of a failure. It can also appear as a first-chance exception that APDFL handles internally. 

Causes and Contributing Conditions

Font-resource configuration is the first area to examine. In a reported case, the application supplied a nonexistent font folder as its only `dirList` entry. Initialization appeared to succeed, but the application later experienced access violations during repeated PDF processing. After the folder path was corrected, approximately 20,000 documents were processed successfully, according to the customer report.

This result supports checking resource paths when investigating the message. It does not establish that every occurrence has the same cause or that the handled exception itself caused the later access violation.

Other possibilities raised during support investigations included an outdated `AdobeFnt*.lst` resource list referencing fonts that were no longer present and insufficient permission to access the actual font files. These conditions were suggested diagnostic leads, not confirmed causes in those cases.

First-Chance Exceptions and Application Failures

A debugger can report an exception before the application's exception handlers have had an opportunity to handle it. APDFL may then catch the exception internally, preventing it from reaching the application's error handler. This behavior is consistent with Microsoft's description of first-chance exception handling.

Check whether execution continues, the requested operation completes, the output is correct, and the application terminates normally. A debugger notification alone does not establish that the operation failed. If the application hangs, crashes, returns an error, or produces incorrect output, investigate that behavior even if the earlier exception was handled.

Resolution Steps

1. **Verify the resource paths used at runtime.** Confirm that the configured font directories exist and contain the intended resources. Check access using the account that runs the application. For relative paths, verify where they resolve in the deployed environment. Also verify any configured CMap and Unicode resource locations.

2. **Check the initialization settings.** For Adobe C/C++ applications, review the resource directory list and initialization flags. `kPDFLInitIgnoreDefaultDirectories` and `kPDFLInitIgnoreSystemFonts` affect which font locations APDFL searches. For Java applications, the `Library` constructors provide font-path, CMap-path, and Unicode-path parameters. Consult the reference for the SDK version and interface in use. See the PDFL Library Layer and Java Library class.

3. **Inspect the font resource lists if paths or fonts have changed.** `AdobeFnt*.lst` files cache information about available font resources. In a controlled troubleshooting run, stop the affected application and remove the relevant generated list files so APDFL can rebuild them. Do not remove the fonts themselves. Rebuilding the lists is a diagnostic step; the cases reviewed do not confirm it as a fix for this exception. See What are AdobeFnt16.1.lst files?.

4. **Verify the font selected by the application.** In Adobe C/C++, use `PDEnumSysFonts()` and `PDSysFontGetAttrs()` to inspect the fonts APDFL finds. `PDFindSysFont()` searches using font attributes and matching flags. In one historical case, an application searching for `Arial` encountered repeated exceptions and hung in `PDFLTerm()`. Changing the application to enumerate fonts and select `ArialMT` allowed termination to complete successfully. This was a case-specific workaround; support did not establish why it worked. See the PDSysFont functions in the PDF Edit Layer API reference.

5. **Retest the complete workflow.** Verify both PDF processing and library termination. For intermittent failures, repeat the workload that previously triggered the problem. Compare the results with an appropriate SDK sample using the same resource configuration.

An upgrade alone is not a documented resolution for this message. 

Additional Support

If the problem persists, contact Datalogics Technical Support