An Internal Error Occurred

[tweetymn]

We are having a problem running PrimoPDF under Windows XP with SP2 installed, with the new Adobe Reader 7.0. We were able to get it working fine with the Adobe Reader 6.0.3, by making the permission changes, etc. However, we have new computers with Adobe Reader 7.0 and the only way we can get it to work is to open Adobe Reader FIRST, then run the program. Otherwise, we get "an internal error occurred" dialog box. Any way to get this to work with Adobe Reader 7.0? :confused:

Also, it freezes the first time you go to use it, and it also freezes on the registration menu. Can those also be fixed. Thank you very much.

[kenrumer]

It seems adobe tries to query the local settings profile as the logged on user. If you give read access to the folder:
"C:\Documents and Settings\LocalService\Application Data"
you should stop receiving this error.

-Ken

[c36po]

Hi,

Are you sure of your path : "C:\Documents and Settings\LocalService\Application Data"
or is it
"C:\Documents and Settings\<user>\LocalSettings\Application Data" ?

Thanks.

[Douglas Saltsman]

Hi,

Are you sure of your path : "C:\Documents and Settings\LocalService\Application Data"
or is it
"C:\Documents and Settings\<user>\LocalSettings\Application Data" ?

Thanks.


That should be it.

It also sounds like you don't have access to all of your registry keys. There should be a registry key for primo under HKLM\software\activepdf\primopdf that you need to have read/write access to

[Re~Silient]

What I have configured:

Regedit and go to

HKLM\SOFTWARE\Activepdf

HKLM\SOFTWARE\Adobe

Right click, Permissions: give Users Full Control.

On XP SP1 error does NOT occur anymore (Print to PrimoPDF, then it launches AR7 no problem)

On XP SP2 (another control system), same config error still occurs but I need to re-test on a clean system.

[Re~Silient]

Myself, I'm waiting to find out if dev. has a real fix or information before I spend more time researching it.

[Dominique]

Ken Rummer's solution giving read access to Autenticated Users on \Documents and Settings\LocalService\Application Data worked fine for us. Problem arose and solution worked for both V1.0 and 2.0.

We also have XP SP2 and Acrobat 7.0 installed and started having those problems for users w /non-admin rights after installing SP2, who of course are the majority.

I keep stumbling, here are 2 more caveats: the users also need Modify-right to the PrimoPDF program directory used to write his temporary file named "temp.ps" (!!) which is not really a good idea, but that the way it's done. Full control to RegKey HKLM\SOFTWARE\Activepdf is required for modifying the default settings, but only if any user may change them for everybody as it's not HKCU which is being used.

Maybe Doug could tell is if there is a configuration setting allowing at least to define an alternate directory for "temp.ps".

Dom

[Re~Silient]

Giving Autenticated Users = Read access (Read & Execute, List Folder Contents and Read) to
Documents and Settings\LocalService\Application Data

Did not work.

Giving Modify (which also adds Write)... did.

Giving Everyone = Modify to
Documents and Settings\LocalService\Application Data

Also worked.

I also still had Users = Full Control on
HKLM\SOFTWARE\ActivePDF
and
HKLM\SOFTWARE\ActivePDF

[Douglas Saltsman]

Ken Rummer's solution giving read access to Autenticated Users on \Documents and Settings\LocalService\Application Data worked fine for us. Problem arose and solution worked for both V1.0 and 2.0.

We also have XP SP2 and Acrobat 7.0 installed and started having those problems for users w /non-admin rights after installing SP2, who of course are the majority.

I keep stumbling, here are 2 more caveats: the users also need Modify-right to the PrimoPDF program directory used to write his temporary file named "temp.ps" (!!) which is not really a good idea, but that the way it's done. Full control to RegKey HKLM\SOFTWARE\Activepdf is required for modifying the default settings, but only if any user may change them for everybody as it's not HKCU which is being used.

Maybe Doug could tell is if there is a configuration setting allowing at least to define an alternate directory for "temp.ps".

Dom


No, there's no way to specify this, but I'll add it to the fix list. It's a hardcoded value, but it could easily be taken from the settings INI.

Although, primo was never really meant to be installed under fast user switching. And if you install the application correctly as administrator, you should be giving access to the programs directory.

[Dominique]

Hi Doug,

Thanks for the reply, but just for the record, we're NOT using fast user switching either.

Giving users full control over a program directory is not a good idea, especially if that right is required for creating some temporary files. There are some better suited places for doing so, such as the %temp%-variable pointing to a temp-folder in the personal directory (in XP) or Windows (earlier versions).

Also, personal preferences settings should definitely be stored in the personal profile rather than the registry HKLM (instead of HKCU!), which would also better suit roaming users.

I hope that's planned in the next version or update but nevertheless, congratulations for this neat piece of software!

Dom

[Dominique]

You're (almost) correct: when printing, the user in fact triggers the Spooler service which is using that account.

[Al B..]

Everything works fine if you have Admin privileges, but my normal users get the 'An Internal Error has Occured'.

FYI~
We are running Windows XP2, Office 2003, Acrobat Reader 7.0.3, and PrimoPDF v2.

So, first I tried the modifed version of the primorun.exe file provide by cgrosvner. This fixed the 'Internal Error' problem, but the file created was the last one created by an admin. (The temp file wasn't updated for the current 'normal' user.) So I change the security permissions on the 'PrimoPDF' folder to allow 'Authenticated Users' to Modify. (I never give them 'full control', they don't need it)

Voila, all is working... My non-admin users can now create pdf docs.

Hope this helps you too.
Cheers!

[sabencat]

Thanks Dominique

The link to the other thread was helpful. I tried the option of editing the permisions on the registry keys:
HKEY_Local_Machine\software\activedpdf
HKEY_Local_Machine\software\adobe

By adding full control permissions to the user account, I can convert ot pdf.

The user account, in this case, is in a non-networked environment with full local administrator rights??? strange that it still did not work correcctly....

Referring to the comments in the link:
http://forums.primopdf.com/showthread.php?t=248

these problems are related to a seat in a networked environment. Comparing the permission levels with a computer in a networked environment before effecting the changes(on the computer that is non-networked),
they are exactly the same. So it is strange that the exact same configuration runs on networked PC, and not in a non-networked PC.

Ruling out firewalls, etc. the rest of the configurations are the same, i.e. Same version of adobe (7), same version of primopdf(1), before upgrading to (2) to attempt to fix the problem.

For other users, refer to the other link for more background info/history on these related issues:
http://forums.primopdf.com/showthread.php?t=387

Cheers

[Andrzej]

I managed to create Novell Application object for PrimoPDF which works for the limited users. I had to substiute the original PrimoRun.exe with posted on the forum http://www.cgrosvenor.co.uk/primorun.zip.
I was not too happy with the idea of giving limited users rights to change files in the C:\Program Files\activePDF\PrimoPDF, but at the time being it is necessary to give all the users rights to modify temp.ps being created in this location.
I managed to accomplish this task by running a batch file:
@echo off
echo y| cacls "C:\Program Files\activePDF\PrimoPDF" /E /T /G users:C
exit
The last step involved modification of shorcuts, I placed both in %*COMMONPROGRAMS%\PrimoPDF and I accociated icon of PrimoPDF_2-0.pdf with C:\Program Files\activePDF\PrimoPDF\PrimoPDF.exe
I also noticed that HKCU registry keys are irrelevant for consecutive users, while HKLM keys permissions did not have to be modified as suggested by previous contributor to this thread

[jcc234]

Are there plans to fix this problem any time soon? If yes, is any kind of time frame available? We really like PrimoPDF but making the security changes listed here is not an option for us.

Thanks.

[ov10mech]

Thanks to all who have tried to help others on this problem. I can say this is enough to make me look at other alternatives than PrimoPDF. Having end users modify windows security to install and use a simple application is not acceptable to me.