Troubleshooting ABCpdf and Installations

It is not uncommon to come across permissions issues when running from ASP.NET.

We offer a three step guide to help you through these. Follow the instructions precisely and you should have no problem.

Step 1. Validate your existing solution

Download and install Open some documents to check that it's working correctly. You may wish to disable the Quickstarter to ensure that the processes are shut down after use rather than kept alive in the background. This may be important if you're going to be changing the user at a later stage.

Build and run the doc2pdf project. If it fails then this would imply a generic configuration issue. Check your OpenOffice installation. Let us know if you can't see a cause.

If it succeeds (as invariably it will) it will imply a permissions issue under ASP.NET.

So assuming it succeeds we need to eliminate the permissions issue. The easiest way to do this is to bypass it using .NET Enterprise Services.

There is an example project ready for you included with your ABCpdf installation. You can find the PDFEnterpriseServices project in the Projects folder under the ABCpdf menu item. All you need to do is build and run it.

Let's assume you're logged on locally as Administrator. All you should need to do is open the solution. Then set right click on the web site project and select it as the startup project. Then run - just press F5.

Note for Vista users with User Access Protection (UAP) enabled. UAP means that Vista switches between user and administrator mode as requested. Visual Studio may not always make appropriate requests during the build process and this can lead to access failures or generic errors. We have found it significantly easier to disable UAP temporarily rather than work through these errors.

Step 2. Deploy to your destination server

Once you've got the .NET Enterprise Services project working on your local machine you may want to deploy it to a remote server.

You should note the following points before deployment:

  1. For server versions of Windows (e.g. Windows 2003 Server) it is important that the latest updates from Microsoft are installed.
  2. It is important that ABCpdf .NET has been installed by running the installer on your server. This is necessary to ensure that ABCpdf is available via the GAC.
  3. It is important that the version of ABCpdf .NET you compile your project against is exactly the same as the version you install on your remote server. If the versions are different, .NET will refuse to load the assembly.

Once you've built the .NET Enterprise Services DLL on your local machine you can copy the project to the remote machine and register the DLL from the command line while logged on locally as Administrator. Simply make the following call from the command line,

regsvcs.exe PdfEnterpriseServices.dll

After you've registered the DLL you should set up a new virtual directory and point it to the web site. Then browse to the site.

If you later need to update the package you must first delete it using the Component Services Administration tool and then re-register the DLL otherwise your changes will not be picked up.

The Identity of the Component Package should be left as the Interactive User. Indeed you should be logged on locally as the Interactive User. By all means change the user later - but please do not be tempted to do this before you have got the package working.

So why do we say this? The problem with changing the user is that each user has to - on first run - accept the EULA. Running as the interactive user you can see this and accept it yourself. If you change to someone who may not have access to the desktop you may never see it and you'll end up with a timeout. It's important to start with a simple scenario so that you know what you're dealing with.

Step 3. Change the Component Package user

The Interactive User is fine as long as you are logged on locally. However this may not always be the case for web servers. So you will most likely want to assign a user to the package.

When you change the user it should be to one that has accepted the EULA. If the user has not accepted the EULA then ABCpdf will time out. In this case you will probably want to copy over the EULA acceptance documentation to the relevant user.

Let's assume you entered appropriate values for the EULA and auto-update settings when you originally ran These are stored in your personal settings on the computer. For example:

C:\Documents and Settings\Michael\Application Data\



So all you need to do is copy these settings to the Component Package user. On Windows 2003 you will probably need to copy the folder to:

C:\Documents and Settings\Default User\Application Data\

On Windows 2008 or Vista 64-bit you will probably need to copy it to:


On Windows 2008 or Vista 32-bit you will probably need to copy it to:


On Windows XP the setup may be slightly different and depending on whether you've set up the Component Package as a Service or not you may find the user settings at one of the following locations:

C:\WINDOWS\system32\config\systemprofile\Application Data\
C:\Documents and Settings\NetworkService\Application Data\

If you're unsure about the location assigned to a particular user you can use Process Monitor from Microsoft / SysInternals (mentioned on the main support page) to find out.

Note that there is a lock file at the top level of the folder which you may need to delete after copying the settings.

Further note that for OpenOffice versions 2.x the folder is called OpenOffice.org2. Since OpenOffice 3.0 it has been renamed to and it contains a sub-folder called 3.

Alternatives to .NET Enterprise Services

You can probably do without Enterprise Services provided you give NetworkService (or your equivalent app pool identity) DCOM launch, activation and access permissions. To do so:

  1. Launch component services (dcomcnfg.exe)
  2. Go to Computers->My Computer->DCOM Config.
  3. Scroll down and look for an application called "Open Office Text Document 1.0" or " 1.1 Text Document" or " Service Manager".
  4. Right click on the application, select Properties and go to the Security tab.
  5. Set the Launch and Activation Permissions to Customize and then click on Edit.
  6. Add NetworkService or your ASP.NET user (or in fact the entire IIS_IUSRS group) and give it full permissions.
  7. Repeat for Access Permissions
  8. If there is more than one Open Office application repeat the process for all of them.
  9. You can also give it permissions for all DCOM applications, not just Open Office, by selecting Computers->My Computer, launching the properties dialog and using "Edit Default" in the COM Security tab.

Note that there are both x86 and x64 versions of DCOMCNFG for separate x86 and x64 settings. By default on x64 versions of Windows the x64 version is launched. To launch the x86 version you will need to perform the following command line operation:

C:\WINDOWS\SysWOW64> mmc comexp.msc /32

Common Problems

The most frustrating cause of problems with are a generic failure to do anything. Typically your process will hang for a minute or two and then finally come back with an error message such as the following.

Retrieving the COM class factory for component with CLSID {82154420-0FBF-11D4-8313-005004526AB4} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).

Fortunately these types of errors are almost always caused by a simple misplacement of configuration files. looks in the AppData folder for the current configuration. If it looks in the wrong folder because the environment is set up incorrectly then it will most likely hang. Most likely it will drop a ".lock" file in this location which will need to be delete to free the process.

For example you might have your configuration files here.


But you might find that is looking here.


The solution is to identify the issue using Process Monitor (filter on AppData or similar). Then you can either fix the environment or you can copy the correct settings over from your AppData folder.