Access denied error for PDFRun.

Topics: User Forum
Nov 7, 2013 at 3:09 PM
Edited Nov 7, 2013 at 4:48 PM
Hey all,

I'm running on AWS micro instance, Windows Server 2008 R2 and IIS 7.5. ActiveVFP demo works fine for basic data access and page creation. But I'm having an issue with the PDFRun DCOM component.

I hope I read all the old threads on this, and I've tried everything I found. I am still getting the "Access denied" dump when I try to run the PDF.avfp page of the demo:
Caught .NET exception, source: PDF.AVFP 000052jt000a err#= 1426 line= 2 OLE error code 0x80070005: Access is denied.1426 OLE error code 0x80070005: Access is denied. 80070005: Access is denied .NULL. .NULL. .NULL. .NULL. c:\inetpub\wwwroot\ActiveVFPDemo\activevfp.dll message: c:\inetpub\wwwroot\ActiveVFPDemo\activevfp.dll
(error is on the CREATEOBJECT() line for PDFRun.Print2PDF.)

I have tried the following:
  • Registered the PDFRun.exe using /regserver.
  • Had to use "mmc -32" to get the PDFRun object to appear in the DCOM listing of the "Component Services" console, but now it appears even without the -32.
  • In the DCOMCNFG console, gave access to PDFRun component to "Everyone" in the DCOMCNFG tool (just to make sure security was wide open).
  • Also gave access to the PDFRun component to users: IUSR, IIS_IUSRS, IIS_WPG, NETWORK SERVICE, ASPNET (did this for "Launch and Activation", "Access", and "Configuration" permissions).
  • Game same permissions to the demo folder (c:\inetpub\wwwroot\ActiveVFPDemo) itself.
  • Set DCOM Identity for the component to interactive user.
  • Even tried setting the Identity to Administrator specifically, still didn't work.
  • Installed the Xerox PS printer and made sure the name matches what is in the PDF.avfp file.
  • Tried making the "Connect As" in Basic Settings of the web site to Administrator and tested connection and it worked. Still get the PDF error, though.
  • Installed VFP 9.0 and use CREATEOBJECT() manually to create the PDFRun object. Works fine, at least as far as creation goes. (This is when I am logged in as Administrator, so I figured it would work fine).
  • Use "iisreset" between every change (total overkill, but I want to make sure -- no one else is using this server....)
  • Reboot the server instance.
No matter what I do, I can't get the PDFRun component to create inside IIS, and it sure seems like a security issue.

Any guidance would be appreciated! Loving the ActiveVFP and just want to make sure I can get extra components (like PDFRun) working!

Nov 7, 2013 at 4:52 PM
Edited Nov 7, 2013 at 5:05 PM
I think you may be missing interactive user somewhere.

See the instructions here

I was missing that one, not sure if it applies to you.

The only other difference was giving full permission to these users to the temp folder specifically ( however that may not be applicable in createobject problem).
Nov 7, 2013 at 5:03 PM
Titu1 wrote:
I think you may be missing interactive user somewhere.

See the instructions here

Thanks for the response!

My sixth bullet point indicates I set the Identity to "interactive user". I also tried a specific user, Administrator, but that didn't help so it is back to what the instructions indicate.

(I did everything in the instructions and then some by opening up all user security to "Everyone" at one point. Still no go.

Since posting, I have recompiled the PDFRun executable directly on the server, unregistered and re-registered, and verified all the DCOM settings once more.

I also removed and reinstalled the PS printer, using "FILE:" as the port type (since that is what the comments in PDFRun indicate to do -- the ActiveFVP instructions about using PDFRun were not clear...)

Still no joy. But, I'm having fun making my own AVFP pages and figuring out how everything else works!

Nov 7, 2013 at 5:31 PM
Yeah, I hate DCOM. And every version of Windows requires different accounts in DCOM. We should create a list per OS of which accounts are required.

I've got IIS 7.5 at home. I'll test tonight and tell you what I have in my DCOMCNFG

In the mean time, since you've tried everything else, you could compile that PDF COM server into a STDLL and see if it just works that way. I think this method bypasses all security requirements since it uses the calling DLLs security (activevfp.dll).
Nov 7, 2013 at 5:43 PM
That's a neat idea, let me go try that!

Thanks for checking into this!

Nov 7, 2013 at 5:56 PM
Compiling PDFRUN as a single-threaded DLL and then using regsvr32 on it (the build probably already registered it, as I can create the object in VFP) now yields the error:
Caught .NET exception, source: PDF.AVFP 000051yh000e err#= 1426 line= 2 OLE error code 0x80004005: Unspecified error.1426 OLE error code 0x80004005: Unspecified error. 80004005: Unspecified error .NULL. .NULL. .NULL. .NULL. c:\inetpub\wwwroot\ActiveVFPDemo\activevfp.dll message: c:\inetpub\wwwroot\ActiveVFPDemo\activevfp.dll
So, it is now just an "Unspecified error".

But then, some progress! I compiled it as a MUTLI-threaded DLL, registered it, and got the error:
Caught .NET exception, source: PDF.AVFP 000055ih0006 err#= 1429 line= 21 OLE IDispatch exception code 1001 from makeps err#= 1001line= 810 Feature is not available.: c:\inetpub\wwwroot\activevfpdemo\reports\pdfrun.dll..1429 OLE IDispatch exception code 1001 from makeps err#= 1001line= 810 Feature is not available.: c:\inetpub\wwwroot\activevfpdemo\reports\pdfrun.dll.. c:\inetpub\wwwroot\activevfpdemo\reports\pdfrun.dll makeps err#= 1001line= 810 Feature is not available. 0 1001 c:\inetpub\wwwroot\ActiveVFPDemo\activevfp.dll message: c:\inetpub\wwwroot\ActiveVFPDemo\activevfp.dll
Line 810 of the main PDFRun program is this:
report form (lcReport) &lcExtra noconsole to file &lcPSFile
Is the "REPORT FORM" command not supported in MTDLLs? I am not all that well versed on DLL usage, but it would seem the multi-threaded DLL solution is getting me the closest (because it at least gets by the CREATEOBJECT() call in PDF.avfp now).

Thanks for the DLL idea, this is at least fun to try to figure out!

Nov 7, 2013 at 6:03 PM
Edited Nov 7, 2013 at 6:06 PM
Yeah, no go on MTDLL - REPORT FORM not supported.
Nov 7, 2013 at 6:11 PM
Yeah, I was just reading up on vfp9t.dll in the help file, and it makes complete sense REPORT FORM wouldn't work in a pure server automator.

I will research STDLL more and see what I come up with!

Nov 7, 2013 at 6:51 PM
I assume you have already tried this i.e. build into 'exe'?

Register PDFRun.exe <Full path of pdfrun.exe file> /RegServer
(e.g. C:\Program Files\dotComSolution\AVFPdemo6\pdfrun.exe /RegServer)

OR just compile the PDFRun project
Nov 7, 2013 at 7:18 PM

Yes, the exe was the first thing I tried, both the one that comes with the demo and then a recompiled exe. Registered it according to the instructions, did all the DCOM stuff, and it still gets the originally posted error.

Nov 7, 2013 at 7:46 PM
One last shot.. when you open VFP, did you open it with 'Run as administrator'? i.e that right click thing of VFP icon? After you compile the exe, do not register. Also, I assume you are doing this on local machine.
Do not forget to check the permissions on the /temp folder.

I am afraid, that is the best I can think of. claudefox is the one who knows it in-depth.
Nov 7, 2013 at 9:59 PM
Well, I have the ability to debug PDFRun now (as a STDLL) by opening up the demo folder for modify access and using STRTOFILE() to dump lines of debugging info.

The line causing trouble (so far) is:
this.cOrigPrinter = set("Printer", 3)
When this fires in the Init(), that results in the "Unspecified error" because the error handler has not instantiated yet.

When that line gets called later (inside SetPrinter() method), the error handling DOES give more info: "Printer is not ready".

When I change all of the SET("Printer", 3) to use SET("Printer", 2) (Windows default instead of current Foxpro printer), then I make it a lot further (I am now getting a 32-bit issue with the GhostScript DLL, so I need to figure that out next...)

Any idea why simply accessing Foxpro default printer would throw a "Printer is not ready" error? Is there some special registration or permissions I need to do for the printer to be usable from the IIS run?

Nov 7, 2013 at 10:59 PM
Summary for the day:

I fixed the GhostScript DLL error by copying the DLL to C:\Windows and C:\Windows\system32. Not sure where it really needs to be, but don't care.

Then things ran without error, but no PDF generation was created. Followed through via my low-tech debugging technique and found out the printer was not getting set right because I changed one set("printer") too many. I changed the last check to see if the printer was set right to use a "3" instead of a "2" and then a printer was properly set.

However, I then end up with an error: "User interface operation not allowed at this time, once again on the "REPORT FORM" line of PostScript generation.

So, it looks like using an STDLL still has issues when it tries to run certain commands? Not sure. All the clauses in the REPORT FORM look OK, and the printer exists (unless it is trying to pop something up in the background -- I will play with the printer more tomorrow...

Anyway, thanks for everyone's help so far! At least I'm learning a lot! smile

Nov 8, 2013 at 9:36 AM
Ok, for STDLL, I knew I had talked with someone about using STDLLs for printing VFP reports and that person was Jon Goad over on Foxite.
See this thread:

Regarding DCOMCNFG for PDFrun as an EXE COM Server, on my IIS 7.5, the accounts I have:

ASP.NET Machine Account
Nov 8, 2013 at 2:56 PM

I appreciate all of your help!

I should have mentioned I found that Foxite thread yesterday, but it didn't help much. I didn't see any specifics in there other than a SET LIBRARY TO (which I added, probably unnecessarily, since I don't think PDFRun uses FLLs). In any case, I didn't get any further. There is nothing in there about the "User-interface operation not allowed at this time" error I ended up with yesterday in the STDLL scenario.

I checked the user accounts in DCOMCNFG and also tried moving the COM exe to C:\Windows. Still get an immediate "Access denied", and none of my debug output makes it to the file (I have a write line as the first line of Print2PDF's Init()). So, it isn't even trying to instantiate the component, it must not think the IIS process has security rights to access it. I must be doing something wrong with /regserver or the way I have launch rights set up (though, it seems so wide open that I am thinking the settings in DCOMCNFG just aren't "taking").

So, I've ended up with the following scenarios, and that is probably where I'll stop for now...plenty of other things to play with:
  • Trying a COM exe I get "Access denied" right from the get-go.
  • Trying an MTDLL I get the expected "Feature is not available" on the REPORT FORM line.
  • Trying an STDLL I get "User-interface operation not allowed at this time" on the REPORT FORM line.
I really do appreciate you taking the time to throw around some ideas and check your DCOMCNFG setup on a working machine!

Nov 8, 2013 at 3:24 PM
Ay yi yi - it just shouldn't be this hard...

I would start from scratch if at all possible. The odds are you may have messed some other settings up along the way, unfortunately.
Nov 8, 2013 at 3:33 PM

That's a good idea, I just added a few data files and one test AVFP file I can save off.

Though, I am not sure how to get rid of the PDFRun component in DCOMCNFG -- there is no delete, and /unregserver does not remove it from the DCOM list even after I refresh...

I don't want to create a whole new AWS instance and start over because then I need to download everything, run updates, and copy the VFP 9.0 DVD up again. Just not worth it.

Still, I can remove and unregister everything I can think of and then install again!

Oh, FYI, there WAS more on that Foxite thread concerning VFP9R and VFP9T.DLLs... I did try moving the run times right beside PDFRun.DLL and register them there, but it didn't change anything for me.

Nov 11, 2013 at 2:14 PM
Hey all,

One last follow-up (and thanks for all the help!)...

I found this KB article that matches the error I get when trying to use REPORT FORM in an STDLL:


I am not sure how other people have ever gotten STDLLs to work with REPORT FORM...TO FILE in order to generate PostScript output, but it's not something I'll be pursuing on any sort of high priority level.

What I found out DID work using REPORT FORM is the ReportListener. I instantiated a ReportListener object and then used:
REPORT FORM (lcReport) &lcExtra NOCONSOLE OBJECT oListener
and that worked without throwing an error. I am pretty sure the listener is being properly attached to the report output because I can access properties like PageNo and PageTotal and see that it changes in the demo based on whether or not I type in a customer name filter.

I was hoping I could easily get straight HTML from the ReportListener, but it doesn't look at all straightforward in that regard (and I don't feel like trying to make an FFC class work in this environment). But, that's merely a shortcoming as to my own knowledge of ReportListener (we're still using VFP 8.0 where I work, and even if we do ever switch to 9.0, I'm not sure we'll have a need for more robust reporting capability).

ANYWAY, it would seem that REPORT FORM can still work fine with an STDLL (still get "Feature is not available." when using REPORT FORM with a listener in an MTDLL) if a ReportListener is employed to wrangle the output. And an STDLL is a lot easier to get working than a DCOM component (compiled as .exe), at least in IIS 7.5 running on Windows Server 2008.

Thanks again for all the help!

Nov 11, 2013 at 3:33 PM
I am not sure how other people have ever gotten STDLLs to work with REPORT FORM...TO FILE in order to generate PostScript output, but it's not something I'll be pursuing on any sort of high priority level.
You should contact Jon Goad via Foxite since he seems to have gotten STDLL from MTDLL working smoothly. And if you started on a new machine from scratch it would probably work without a lot of hassle. Plus it would help everyone else out if you proved it's working with AVFP :)

Thanks for showing that Reportlisteners work with AVFP. I'm not sure why they would work and not Ghostscript in a COM STDLL but my guess is a misconfiguration somewhere on your machine.
Nov 11, 2013 at 4:00 PM
claudefox wrote:
You should contact Jon Goad via Foxite since he seems to have gotten STDLL from MTDLL working smoothly. And if you started on a new machine from scratch it would probably work without a lot of hassle. Plus it would help everyone else out if you proved it's working with AVFP :)

Thanks for showing that Reportlisteners work with AVFP. I'm not sure why they would work and not Ghostscript in a COM STDLL but my guess is a misconfiguration somewhere on your machine.
It was my impression from the Foxite thread that Goad was using XFRX to convert report output to PDF. Not sure what that uses under the hood, but at $149 bucks for the PDF-only version (an entirely fantastic price for a royalty-free converter!), I am wondering if it might use more of an Adobe-licensed conversion rather than relying on PS printer stuff (I don't see any requirement to install special printers or anything in doing a quick perusal of the XFRX documentation...) Additionally, it looks like the VFP 9.0 version of XFRX taps into the ReportListener, so perhaps they get away with using REPORT FORM the same way I mention above (if they even use it at all).

In any case, if I need to pursue it further at some future time, I will. For now, probably the most I will do is try to install IIS Express on my XP machine and see if PDFs generate from the COM exe version of PDFRun. Then I will try the STDLL as well.

As far as why a ReportListener works in REPORT FORM while "TO FILE" does not, my guess is that REPORT FORM is simply put into a more modal behavior when it uses a non-object based output method (something to do with the preview window, even when going straight to file/printer?). The Ghostscript stuff actually doesn't have anything to do with it -- it was never reaching the PS --> PDF conversion code when I was getting the user interaction error, and when I got past that with ReportListener, no PS file was being generated. So, the GS code never really even ran. I have no reason to believe it wouldn't, though, as it was based all on DLL calls to GS32DLL.DLL. Really, the only PDFRUn issues here were with getting permissions to work with the DCOM exe, or making the STDLL work by avoiding all modal/interactive code (and REPORT FORM appears to be the only tricky aspect of that...)

Nov 11, 2013 at 4:06 PM
Edited Nov 11, 2013 at 5:11 PM
To be clear, using an STDLL (or even an MTDLL) library from AVFP totally appears to work -- you just need to be careful about what the DLL tries to do (moreso in the MTDLL with all of the features it does not allow to be available). As I said above, it would seem the only line of PDFRun that caused a problem was REPORT FORM...TO FILE.

I was able to put data access programming in a DLL method (take a SQL query with full path to data) and return the recordset as an array of information (cursors don't share, obviously). COMARRAY() was necessary for this to work. You can also communicate via temporary files (like how Print2PDF returns a link to the PDF generated from FRX). This sort of programming and communication worked equally well in STDLL/MTDLL, so you could "code behind behind" in a DLL all you want as far as I can tell...

Nov 11, 2013 at 5:58 PM
One more follow-up...

Installed IIS Express on Windows XP (thanks for the instructions on getting that to work, Claude!).

ActiveVFP site works fine, and all I had to do was register PDFRun.exe to have PDF generation work (well, that and to use the PS printer I already have set up for my home-grown PDF generation in our apps). No additional security settings or anything were needed to make the default-packaged PDFRun.EXE work as a COM server.

Recompiled PDFRun as an STDLL, and got the same user interaction error as I was getting on the AWS Windows 2008 server. So everything works about the same, except DCOM is more of a pain on Windows Server 2008 such that I irreparably made the PDFRun.exe non-workable on there with "Access denied" errors.

On Win XP, the PDF output redirection does not match where the file actually goes (names the web site name one extra time in the path), but that is likely do to an error in how I set up the site in IIS Express's site configuration file. The PDF files are clearly being generated from the Foxpro FRX.