Technical FAQs

Question

Why do I get a “80040154 Class Not Registered” error when using the License Development Kit on IIS?

Answer

If you are receiving a “80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).” error while trying to use the LDK on a website created through IIS, it is likely because of a platform conflict (x32 vs x64). To fix it, try checking (or unchecking) “Enable 32-Bit Applications” for the App Pool associated with the website.

Question

Why, when I tried to run the SLU, do I get a ” Component ‘COMDLG32.OCX’ or one of its dependences not correctly registered” error?

Answer

This error happens if a particular deployment machine doesn’t have the COMDLG32.OCX file registered. To fix this: 1.   Install the comdlg.ocx dependency, if not available on the target machine. If the comdlg.ocx is not present on the system than it will need to be obtained from a system that has it (it should be available on your development machine in the directory mentioned in step 2). 2.   Place the file in the C:\Windows\System32 folder. (C:\Windows\SysWOW64 on a 64 bit machine) 3.   Register the DLL via the regsvr32.exe command. 4.   You should see a successful message and then be able to proceed with the licensing installation.

Question

In PrizmDoc, why do I fail to load/convert Excel documents with the error “Exception from HRESULT: 0x800AC472”?

Answer

The error message Exception from HRESULT: 0x800AC472 is usually associated with a failure involving an Excel document, found in the MsOfficeConverter.log. Below are some known triggers of it:

If the user is logged in as "SYSTEM", "LocalSystem", or any other non-user-account variant, this will cause PrizmDoc to fail when using MSO services. This is expected behavior when working with Microsoft Office documents in PrizmDoc. Please see step 6 of the Windows Installation documentation regarding this:

http://help.accusoft.com/PrizmDoc/latest/HTML/webframe.html#windows-installation.html

"Specify the login account (account name and password) that PrizmDoc Server will run under. If you are using the Microsoft Office (MSO) Conversion add-on, please make sure that the "login account" is a real user account with Administrator rights. Running PrizmDoc under the LocalSystem user or another Microsoft Windows integrated service account is not supported for this option."

It’s also crucial that the copy of Microsoft Office on the system has been activated. A not-licensed, not-activated, expired, or trial license will all cause Microsoft Office to not work with PrizmDoc.

More information: https://help.accusoft.com/PrizmDoc/latest/HTML/windows-requirements.html

"The installed copy of Microsoft Office must be activated in order for PrizmDoc’s Microsoft Office Conversion Service to work properly. Not licensed, not activated, an expired or trial version of Microsoft Office will not work with PrizmDoc."

Your default printer must be the Microsoft XPS Document Writer when working with Excel documents in PrizmDoc. Specifying another printer could possibly lead to this exception.

More information: http://help.accusoft.com/PrizmDoc/latest/HTML/natively-render-mso-documents.html

"The Microsoft Office Conversion Service requires the Microsoft XPS Document Writer printer driver to be installed for the best conversion performance and rendering fidelity of MS Excel documents"

Ensure the Print Spooler service is started and the Microsoft XPS Document Writer is the default printer.

There is a known issue with version 13.3 of PrizmDoc where completely blank Excel files are not loadable in the Viewer. They will fail to load and throw the aforementioned HRESULT exception. This has been fixed in PrizmDoc version 13.6.

In short, please set up the PrizmDoc service correctly to run with a real user account, ensure the copy of Microsoft Office has been activated, and make sure the default printer is set to "Microsoft XPS Document Writer", then restart the service. This should fix this particular issue in most cases.


For more reading on considerations that Microsoft recommends when running their client-side MSO applications on the server, see this article:

Considerations for server-side Automation of Office

document redaction

Many professionals in highly regulated industries like legal, healthcare, and government handle a myriad of cases, contracts, and forms. However, collaborating on documents comes with a risk. Sharing personally identifiable information (PII) with the wrong person can cause chaos and even result in a lawsuit. That’s why redaction is so paramount to collaboration in so many industries. Where manual paper processes once required a permanent marker, digital solutions now offer redaction capabilities that work even better. 

Redaction removes key pieces of information — including sentences, images, and even entire pages — while leaving the bulk of the document’s text intact. Although many tools now empower organizations to “burn in” data redaction so it can’t be removed, they don’t allow users to indicate multiple reasons for redaction. 

Many solutions offer a coding system that enables users to tag a piece of redacted information with a single reason code that signifies why the data was hidden. However, they lack the ability to add those reasons while you are redacting, which could save time and effort. Just think of how large some of these files could be, and how manually adding comments throughout the document could take hours after you’ve already finished reviewing the content.

This creates additional pressure from viewers to understand the purpose of redaction, and potential reporting issues if the reason for redaction isn’t properly recorded. Solutions that permit the addition of redaction reasons can help defend key data and close this communications gap.


The Freedom of Information Act (FOIA) and Secure Data Sharing

As noted by CNN, government documents are often partially redacted to obscure personal data such as social security numbers or military information related to intelligence data gathering and applications. Consider a U.S. intelligence agency report made public by FOIA request. 

While the Freedom of Information Act forms a critical part of open, effective democracy, data in the report that suddenly becomes public domain — such as the names of confidential sources or the methods used to obtain information about foreign government actions — could jeopardize both the ability of the agency to do its job and put human lives at risk.

Most government redactions expire and are automatically declassified after 50 years, but agencies can also obtain permission for special exemptions which prevent the redaction from being removed. For example, redaction reason 3.3(h)(1)(a) is used to protect the identity of a classified human intelligence source and is exempt from automatic expiration.

There are currently nine FOIA exemptions that are withheld from public release and protected from disclosure. When a portion of a record is withheld from public release, an exemption code may be found listed in the margin. The Federal Bureau of Investigation’s list below showcases what exemption codes are subject to FOIA data withholding:

  • (b)(1) (A) Specifically authorized under criteria by an executive order to be kept secret in the interest of national defense or foreign policy and (B) are in fact properly classified to such Executive Order #12958 (3/25/03).
  • (b)(2) Related solely to the internal personnel rules and practices of an agency.
  • (b)(3) Specifically exempted from disclosure by statute (other than section 552b of this title), provided that such statute (A) requires that the matters be withheld from the public in such a manner as to leave no discretion on issue or (B) establishes particular criteria for withholding or refers to particular types of matters to be withheld.
  • (b)(4) Trade secrets and commercial or financial information obtained from a person and privileged or confidential.
  • (b)(5) Inter-agency or intra-agency memorandums or letters that would not be available by law to a party other than an agency in litigation with the agency.
  • (b)(6) Personnel and medical files and similar files, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.
  • (b)(7) Records or information compiled for law enforcement purposes, but only to the extent that the production of such law enforcement records or information:
  • A. Could reasonably be expected to interfere with enforcement proceedings;
  • B. Would deprive a person of a right to a fair trial or an impartial adjudication;
  • C. Could reasonably be expected to constitute an unwarranted invasion of personal privacy;
  • D. Could reasonably be expected to disclose the identity of confidential source, including a state, local, or foreign agency or authority or any private institution that furnished information on a confidential basis, and, in the case of a record or information compiled by a criminal law enforcement authority in the course of a criminal investigation or by an agency conducting a lawful national security intelligence investigation, information furnished by a confidential source;
  • E. Would disclose techniques and procedures for law enforcement investigations or prosecutions or would disclose guidelines for law enforcement investigations or prosecutions if such disclosure could reasonably be expected to risk circumvention of the law, or;
  • F. Could reasonably be expected to endanger the life or physical safety or any individual.
  • (b)(8) Contained in or related to examination, operating, or condition reports prepared by, on behalf of, or for the use of an agency responsible for the regulation or supervision of financial institutions.
  • (b)(9) Geological and geophysical information and data, including maps concerning wells.

Given these extensive reasons, we can start to understand how there might be reason to include multiple FOIA exemption codes for one piece of redacted information.


Regulatory Compliance & Document Security

For many organizations, adding redaction reasons to shared or publicly-available documents isn’t mandatory, but it can help reduce the risk of both legal and compliance challenges. 

Consider a redacted court document shared as part of an eDiscovery process. Without a custom redaction reason, other parties may challenge the necessity of your redaction, especially if no contextual evidence indicates its necessity. 

Compliance audits also pose a potential problem. If years or even decades-old documents don’t contain redaction reasons — and the originals aren’t easily located — your organization could face increased regulatory oversight.

Take for example the healthcare industry. There are several clinical studies that require peer review. To keep biases at bay and personal information secure, redaction is critical to the adjudication process. Think about a clinical trial that has specific events related to a test subject. That test subject has participated in a trial for an incentive. 

However, that person did not agree to share his or her personal information with a broad audience. Once the panel of experts reviews the results of a clinical trial, the research goes on public record. It’s crucial to protect the participants involved and their PII to ensure that no harm comes to them.

Many document viewing tools make it possible to add single redaction reasons to released documents, but what happens if your organization is dealing with multiple data types? Look for a solution that enables you to add multiple redaction reasons or codes to clarify your intent and keep data secure.

Question

When licensing my PrizmDoc server, I get the error “Unable to write licensing information to the properties file.” Why is this happening?

enter image description here

Answer

To resolve this issue, please try the following:

  1. Re-run the Prizm Licensing Utility as an administrator.

  2. The Prizm Licensing Utility is writing to Prizm/prizm-services-config.yml. See whether you have permissions to edit this file.

  3. Check whether Prizm/prizm-services-config.yml is locked by another process. If you have it open in some text editing software, PrizmDoc may not be able to write to it.

Additionally, if you have an OEM key, you can just manually enter this key into the file by placing the following at the top:

license.solutionName: ENTER_YOUR_SOLUTION_NAME_HERE

license.key: 2.0…rest_of_the_key_goes_here

Question

The http://localhost:3000/servicesConnection returns a 580 error. What could the issue be?

Answer

This indicates that PAS cannot communicate with the backend.

To fix this, verify that the PCCIS connection configuration section of pcc.*.yml is correct and that the backend is healthy and listening.

If the issue persists, check the logs/pas/pas-*.log files for network related issues.

For more information, see the Connection Issues topic.

Question

Why is the searchTasks endpoint returning an invalid JSON from very large requests?

Answer

Though no official size limit has been published, PAS will return a misleading invalid JSON error if you send in several thousand search terms at once. The exact maximum seems to vary across different installs. We have logged a story in our backlog about making a more explicit size limit possible, but there is no current plan to allow for PrizmDoc to handle search requests of unbounded size.

The best workaround for this behavior is to split your search terms between multiple requests, rather than packing them into one request.

Question

We are currently using PrizmDoc Cloud licensing. After applying our cloud license, the Prizm services started and show healthy, however, I see “CloudLicenseValidationFailed” errors in the PccErrors.log file. Is this normal, and do I have to worry about Prizm functionality?

Answer

Currently the licensing messages referencing “CloudLicenseValidationFailed” in PccErrors.log are a false positive and should not be taken as an issue with PrizmDoc Cloud licensing.
The more accurate way to check whether the license has been validated successfully would be to use watchdog.log and look for “Cloud License Validation” – “isValid”:true which indicates that the license is valid.

The issue regarding that error in pccerrors.log is in our product backlog to consider addressing in a future release, but it is not yet prioritized on our roadmap.