1

I have problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.

In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.

I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)

Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.

Gui.exe is a part of bullzip.

If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.

To solve this problem i need to find out one of two and how to fix it:

  1. What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
  2. What is the difference in running NAS as service and as command line that could cause application to crash when run as service.

What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.

Any alternative free pdf printers advices are welcome.

This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.

Mak Sim
  • 2,148
  • 19
  • 30
  • Hmm, I use BullZip within NAV (both service tier, the classic client) so I wouldn't think it's BullZip itself. I've suggested a possible fix. – Jake Edwards May 21 '13 at 22:58
  • Have you used it under local admin account? By service tier you mean NAS or web-services/RTC? Because I faced this problem only related to NAS. Will test it with WS today. – Mak Sim May 22 '13 at 07:24
  • It seems like it's not possible to print from web-service at all. – Mak Sim May 22 '13 at 08:16

2 Answers2

0

We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.

The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.

We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.

Jake Edwards
  • 1,190
  • 11
  • 24
  • Yes I've used domain account but with different rights (local admin and local user). And yes, I've tried to to use procmon. The only thing i've found is that under user account gui.exe crashes when it comes to `lpk.dll` in system32 folder. Don't know what to do next. This dll have permission for all users and i can't add or change them even as administrator. – Mak Sim May 22 '13 at 07:21
0

I think re-installing the application will do that,

Just make sure you are uninstalling each bullzip and ghost script,

Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,

refer this download link download appropriate version, install it,

and then install bullzip, after downloading new version from here

this will do..

then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..

where you need to use public class PdfSettings with namespace bioPdf.

I hope this will help ..

MarmiK
  • 5,639
  • 6
  • 40
  • 49
  • Thanks for your answer but none of this explains why its working under _admin account_ and not working under _regular user account_. I don't think there is a difference in handling 64 bit applications with different user rights. – Mak Sim Jun 20 '13 at 06:31
  • Its because, while installing it will ask you install for all users, if that is not checked the it will be installed for the admin only :) – MarmiK Jun 20 '13 at 06:38
  • Yes server 2008 was having problem with ghost script and rights, same with Win 7; I have seen that issue so I installed, as some time ghost script is blocked by the windows firewall/i mean defender.. – MarmiK Jun 20 '13 at 06:39
  • As far as I know software cannot be installed for builtin user group. And what I'm talking about is when I include user (any user) to builtin administrators group on local machine solution starts working under this user's account. So I'm talking about rights not particular users. And if problem is solved by changing a rights somehow it shouldn't be a 32/64 bits problem. Right? – Mak Sim Jun 20 '13 at 06:45
  • I got that its not 32 bit problem, i was saying it may be, sorry if I have misinterpreted, Please try new version i am sure this will do, and concentrate on ghost script as that is blocked by win defender. So if possible add that app to exception that will work fine with all user.. defender does not ask limited user for permission it will just block' – MarmiK Jun 20 '13 at 07:10