c#/Access 2010 - DoCmd.OutputTo error running from task scheduler - c#

I have a c# console application running daily as a scheduled task.
Recently I've added a new functionality to send an e-mail with an attached pdf report, using Access 2010 built-in pdf export:
using MsAccess = Microsoft.Office.Interop.Access;
//(...)
AccApp = new MsAccess.Application();
AccApp.Visible = false;
AccApp.OpenCurrentDatabase(DBPathname, false);
AccApp.DoCmd.OutputTo(MsAccess.AcOutputObjectType.acOutputReport, "GMB_CSS_Report", "PDFFormat(*.pdf)", ReportFilename, false, Type.Missing, Type.Missing, MsAccess.AcExportQuality.acExportQualityPrint);
//(...)
When I run the new version interactively on the command line it works well, exporting the report as a PDF to the designated path\file.
But when I run it from task manager, using the same credentials, it crashes on the DoCmd.OutputTo(...) statement with the error:
(System.Runtime.InteropServices.COMException) Microsoft Access can't save the output data to the file you've selected.
That does not make any sense, as the application successfuly writes several other files to the same folder, running either from the console or from the task manager.
I've also found that the application runs without the error as a scheduled task on a third PC, not integrated in the company AD domain (the production and dev hosts are on the domain), even though all 3 hosts have the same s/w level (Win7 SP1, Access 2010 updated to latest patches via Windows Update).
This is bizarre... am I missing something here ? Any suggestions will be greatly appreciated.
Thanks in advance.

I think that your problem is in the "PDFFormat(*.pdf)" constant string.
The right one for PDF is this:
public const string acFormatPDF = "PDF Format (*.pdf)";
And this is for RTF:
public const string acFormatRTF = "Rich Text Format (*.rtf)";
I still have got problems with the same function on a 64Bit version of Access 2010 running on Windows 2008 Server 64Bit, while it works perfectly on a Windows Server 2003 machine 32bit with Access 2010 32bit.

Related

IronPDF Renderer.RenderHtmlAsPdf failing when deployed to IIS

We are using ironPDF to genetate PDF file from HTML string. It is a MVC web application written in C# (.net framework 4.8) , deployed to IIS
I did the following.
Added IronPdf nuget package to the project (Version: 2022.11.10347)
Use the following code to generate PDF from string
using IronPdf; (on top of the code to add ref)
PDF generation code as below;
public ActionResult ExportPDF()
{
var Renderer = new IronPdf.ChromePdfRenderer();
var pdfDoc = Renderer.RenderHtmlAsPdf(htmlstring);
return File(pdfDoc.Stream.ToArray(), "application/pdf", "TransactionStatement.pdf");
}
here htmlstring is the html that need to be rendered to PDF
This code works fine and generates PDF when I run in my local dev machine.
But when I deploy this code to our integration environment , it is failing. It is not generating any PDF.
It just hangs for couple of minutes then our website is getting timed out and application pool is getting stopped.
the failure is happening is in the following line
var pdfDoc = Renderer.RenderHtmlAsPdf(htmlstring);
Out integration environment is in IIS (Windows server 2008 R2) . and application pool identity is NetworkService.
When I looked into the event log I can see the following warnings
Application popup: IronCefSubprocess.exe - System Error : The program can't start because api-ms-win-core-com-l1-1-0.dll is missing. from your computer. Try reinstalling the program to fix this problem.
A process serving application pool '<poolname>' suffered a fatal communication error with the Windows Process Activation Service. The process id was '5940'. The data field contains the error number.
I have all required Visual C++ redistributables installed in my server as described in the ironPDF website
Any idea how to fix this issue.
For API-MS-WIN-CORE-COM-L1-1-0.DLL. You could refer to this to reinstall API-MS-WIN-CORE-COM-L1-1-0.DLL.
About application pool error. As the community member said, need configuration information is needed to locate the cause.
In my opinion, you could try turn Enable 32-bit applications to true. If still don't work, you can refer to this using debugging tools to locate the cause.

How to install ABCpdf without Admin Privs?

I have a project in visual studio written in C# that uses ABCpdf to create a PDF page count. I set the install to be instanced as the project is deployed on a server and the project is run without admin rights as our IT department does not want to have a GMSA with admin privs to run it (it runs as a nightly windows task schedule). My issue is the application fails when it tries to generate the PDF due to access denied when installing the license. If I run the application as administrator on the server it runs fine, so it's definitely something to do with no admin rights when installing the license (or other aspects perhaps to run).
My code for installing looks like this:
try { string sResult;
if (WebSupergoo.ABCpdf11.XSettings.InstallRedistributionLicense("<license string>"))
{
sResult = "License Installed Successfully: " + WebSupergoo.ABCpdf11.XSettings.LicenseDescription;
}
else
{
sResult = "License Installation Failed";
}
<does other formatting things for the pdf creation after this in the try catch>
Does anyone know how to get this working without admin rights, or do you know the specific task or registry item it modifies so I can give the GMSA access just to that without full privs? Any help would be awesome. Thanks in advance!

mso20win32client.dll error when initializing new_RDOSession

I am getting errors in event viewer every time my application runs this line:
Redemption.RDOSession rSession = RedemptionLoader.new_RDOSession();
event viewer error:
faulting application name: (my.exe)
exception code: 0xc0000005
faulting module path: C:\Program Files\Common Files\Microsoft Shared\Office16\mso20win32client.dll
The oddest part is that it proceeds to create the session and makes it to the end of my code if I let it, successfully looking up an email in Outlook. This is in production and has worked for years, but for some months now it has been racking up the same error in Event Viewer. End users don't notice, but IT is seeing thousands of errors now which makes it hard for them to know when other problems might be showing up.
I reproduced this on the first try with:
Windows 10 Home, OS build 19044.1706, Windows Feature Experience Pack 120.2212.4170.0
Outlook: Microsoft® Outlook® for Microsoft 365 MSO (Version 2205 Build 16.0.15225.20172) 64-bit
I added logging in my CS code to make sure this caused the error. The error occurs if set ignoreoutlook to "e", and not if I set it to "d":
Microsoft.Office.Interop.Outlook.Application oApp = (Application)Marshal.GetActiveObject("Outlook.Application");
if (ignoreoutlook.Equals("d")) return;
Redemption.RDOSession rSession = RedemptionLoader.new_RDOSession(); // new Redemption.RDOSession();
if (ignoreoutlook.Equals("e")) return;
As for:
C:\ProgramFiles\Common Files\Microsoft Shared\Office16\mso20win32client.dll
it doesn't exist. There is a dll of that name in both:
C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\OFFICE16
C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16
If Redemption wants to use that dll, how is it working without it?
Is there a way to configure Redemption to skip that dll and move on to whatever else it must be doing to get it to work after that error?
There are quite a few things going on once the MAPI system (when Redemption loads it and calls MAPIInitialize) initializes common Office runtime, which has a bunch of its own problems, since it loads telemetry and licensing. Some of that functionlity only works when running inside the (virtualized) Office app environment (it patches a few Win API functions etc.)
Check if you see the same problem in MFCMAPI if you log to a profile (to ensure the MAPI system is loaded). If you do, that means the problem is in the MAPI system and you can work with MS support. If not, something is specific to your app.
One thing to keep in mind is that your app must embed a manifest and advertise its support for Windows 10. Otherwise common Office run-time tries to patch wrong Win API functions.

ServiceBase service error 193:0xc1 on Windows XP

I have a service that I've built using the C# ServiceBase class. It works when I run it in Windows 7 and Windows Server 2008; however, it doesn't work on Windows XP.
I created the service using sc create PBUService binpath= "C:\PBULogger.exe". This is the correct path.
Nothing is logging in the Event Viewer under anything and my exception handling code doesn't fire either.
I thought maybe I didn't have the correct .NET version installed, but I have 4.0 installed on the XP machine. However, I created this project using Visual Studio Express 2012, which I'm pretty sure uses .NET 4.5 by default. Is this causing an issue? All the classes I'm using are version 4.0.
I have stripped down all my code to the base methods and this still doesn't work. Here is my code:
namespace PBULogger {
class PBULoggerService : ServiceBase {
protected override void OnStart(string[] args) {
try {
base.OnStart(args);
} catch (Exception ex) {
EmailUtility.sendEmail("Service Error", ex.Message + ex.StackTrace);
}
}
protected override void OnStop() {
base.OnStop();
}
}
Since it doesn't log in the event viewer, it tells me it isn't even trying to start the service.
I found these entries in my registry for the service under 'HKEY_LOCAL_MACHINE/System/ControlSet001/Enum/Services/PBUService/Enum'.
Not really sure what it means.
Anybody know what's going on?
You must have compiled your exe either for .Net 4.5 or for 64-bit architecture (or both). This is the explanation of error code you run into from WinError.h:
// %1 is not a valid Win32 application.
//
#define ERROR_BAD_EXE_FORMAT 193L
Make sure you have compiled it for x86 platform or Any CPU, and whatever version of .Net Framework you compiled against is installed on the machine.
I found this after googling the windows service error number:
*Generally the error message means that the service manager couldn't find the exact .exe path to run the service. Sometimes, the service is installed from a directory with multiple words for the directory name. So the registry path to the service needs to be placed with double quotes.
Click ‘Start’ and type ‘services.msc’ and hit Enter
Check for the multimedia class scheduler and audio endpoint builder service.
Check for the path under "path to executable:" for both the services. Make a note of the same.
Also make a note of the service name for both the services.
The services are as follows:
AudioEndpointBuilder - AudioEndpointBuilder
Multimedia Class Scheduler - MMCSS
Now, let’s check if the paths under these two services are the same as well in the registry.
Click ‘Start’, type regedit and hit Enter
Locate the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Under services, check for these services: MMCSS and AudioEndpointBuilder.
Corresponding to the above two services, the Image path (on the right pane) should be same as the path in ‘services.msc’*
I found it here
In our case this happened after a server crash and the exe file got corrupted. We re-deployed the binaries and then the service started successfully.
In my case, this was due to building with target of 64-bit only. I forgot that one of my test servers running Server 2003 was 32-bit. My service runs fine on the 64-bit Server 2008 R2 box.
I think that there is a compatibility problem with .net framework that you use and windows server 2003.Do you use .net 4.5? Windows server 2003 can't run applications which target net framework 4.5.
http://www.microsoft.com/visualstudio/eng/products/compatibility
So you could change your target framework to 4.0.

Open ACCESS Application thru C# Application on windows 7

Some background:
we have a windows application (c#) that locate in the system try.
that simple application is a basically shortcuts manger for other application and messaging between the workers.
one of the application is an Access 2007 application (connected to sqlserver) - the client works with ACCESS Runtime 2007 (latest version)
THE problem is that we can not launch the Access application correctly from the C# application.
THE problem is only on windows 7 (we don't have vista) - [on XP OS everything works fine)
"correctly" - meaning that the Access application running but the Ribbon Bar is missing some Icons (strange). also some functionality like open the Outlook is not working.
Some more Info:
- IF we put shortcut on the client desktop to the Access application everything ok.
- The C# application have no problem to launch other EXE file.
- The C# application include Manifest file (run as admin on Win 7).
The Original code is very simple (Works only in XP):
System.Diagnostics.Process.Start(AppPath);
The 'Open EXE' code that works (Works on XP and Win7)-[not working with Access Application]
Process Proc= new Process();
Proc.StartInfo.UseShellExecute = false;
Proc.StartInfo.FileName = Application.StartupPath + #"\PasswordManager.exe";
Proc.Start();
We try many codes with no success like [NOT WORKING]:
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.EnableRaisingEvents = false;
proc.StartInfo.FileName = sAccPath;// msaccess Path;
proc.StartInfo.Arguments = #"""" + AppPath+ #"""";
proc.Start();
We also try to add [NOT WORKING]:
System.OperatingSystem osInfo = System.Environment.OSVersion;
if (osInfo.Version.Major > 5)
proc.StartInfo.Verb = "runas";
Helppppppppppp!!!
Thanks
I could be wrong on this, but my guess is that it's running in reduced functionality mode due to your not defining a trusted location from which it can run. I don't know how this is done in code, but if you launch A2007, it's on the Office menu under Access Options (I'm posting from menu, as I mostly use A2003 and don't want to wait through the re-registration process).
We uninstall current OFFICE SBE 2007 and Install a newest version of OFFICE SBE 2007.
everything works fine now.
our conclusion is that Office SBE 2007 first version (instaled at client computer) doesn't work well with Access Runtime 2007.
(weird, but work)
David, Thank You very much.

Categories