I have a windows service that prints InfoPath form's default view using the xdocument.PrintOut() function. It works on several machine configurations except one case. It does not work on some machines running Windows 2012 (and Win2012R2) (x64), SharePoint 2013 (x64), and Office professional plus 2013 (x86). I am not sure if SharePoint has anything to do with the issue.
Here is what's happening when I checked the difference on the process monitor logs.
When executed as a windows service and xdocument.PrintOut() is called, it launches INFOPATH.EXE in background, sends print command, initiates the spoolsv.exe (Printer Spooler), printer spooler detects the default printer and nothing happens afterwards.
When the same code is executed using console app, similer set of events happen and in addition it creates spooler files at "C:\Windows\System32\spool\PRINTERS\FP00003.SPL" and "C:\Windows\System32\spool\PRINTERS\FP00003.SHD". SPL files are the actual spool (print job) files. SHD files provide information about which printer the print job was sent to and from whom the print job came.
Please note that the service runs under the same account as when running the console app and the printer driver is always the same on all systems. Also, running exactly the same code, but by automating MS-Word to print to the same printer from a service, works fine as well.
I tried to explain the problem and please feel free to ask clarification through comments.
Here is the code used in Windows service and console app:
//** Create inforpath application instance
Microsoft.Office.Interop.InfoPath.Application app = new Microsoft.Office.Interop.InfoPath.Application();
//** Open XML file
XDocument xdoc = app.XDocuments.Open(#"F:\InfoPathTestFiles\8f2de6cb86594203b5ecb301cb2f4a94.xml", 1);
//** give enough time for infopath.exe to open the XML file
System.Threading.Thread.Sleep(5000);
//** Send print command.
xdoc.PrintOut();
//** let it cool for 5 seconds.
System.Threading.Thread.Sleep(5000);
//** quit the application.
app.Quit(true);
Please note that the InfoPath file (xml) needs to be fully trusted in order for it to print in this manner.
Related
Im trying to print a generated pdf on my web app in c# asp.net.
Im using iis.
I need to print the file on a specific printemps over our network. The fact is that in my dev server environnement, in debug, everything works well.
I use process.start(foxitreader exe, the file, and the printer)
But when i release the app, on the prod server ,no more printing. All i got is the process of the terminal and foxit reader showing in task manager, but that’ it.
My question is : is there a way to print my file with This configuration ?
I tried to launch the powershell command directly in terminal, it worked on Both server.
I tried to launch a ..bat file directly that open the powershell script, it worked as well.
But from the app, i still can’t figure how to make it work
I need help with a strange problem that I can't solve. I developed an API as a local server to manage print requests between a web application and the user's PC.
This API is executed by a Windows Service, and it is packaged in an MSI installation package.
So the user installs the Windows service that runs an API on his computer. If the user needs to print something, the web application creates an API request on localhost with the printer parameters and calls the PrintDocument method.
My problem is that when the API calls PrintDocument.Print() after preparing the configuration, nothing happens. Windows print spooler shows that you have a printed document and does not throw an exception or error. And this only happens on the user's PC after installing the service, and it only happens with PDF printers! Physical printers work fine, and debug mode with any printer, including a pdf printer, works fine too.
Any ideas why happens this behaviour?
Thanks!
My code
PrintServer is a class that inherits from System.Drawing.Printing.PrintDocument
It's probably failing from a service because PDF printers need to pop up a file save window and can't do so because it's running under the service context. If you specify a file name, you may be able to avoid this pop up. You can do this by setting the PrintToFile and PrintFileName properties in PrinterSettings:
printer.PrinterSettings.PrintToFile = True
printer.PrinterSettings.PrintFileName = "path-to-pdf.pdf"
My program, run via a Windows Service was able to successfully run the following code under Win7 and Win8.
Log("About to run the file...");
try
{
Process.Start(filePath, args);
Log("File Triggered!");
}
catch (Exception ex)
{
Log("Error.");
}
Although the UI of the program located at filePath was never shown, but the program did its job completely in the background.
When I try the exact same program on a Windows 2012 R2 environment, I notice that after receiving the first log message above in my log file ("About to run the file...") nothing else is logged and Process.Start() does not work either. This is confusing because the exact same program worked in other operating systems.
So if Process.Start() is not called successfully, who do I not receive the "Error" message in my log and if Process.Start() is run, why do I not get the "File Triggered!" message?
Update:
Following the comments, I ran Process Monitor and this is the log generated for the target .exe file at the exact minute that it was supposed to run. Please take a look and see you find anything suspicious:
Link to log spreadsheet on Google Docs
I think this is because Windows Server 2012 does not by default allow processes to run interactively.
See here for details.
You can override this behaviour by setting a registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows
NoInteractiveServices
Set the value to "0".
What's in process viewer -- do you see your process to start?
What's in Windows Event Log?
Win2012 is probably more strict regarding security and your application (executed from service, thus quite specific user). You can try using FileMon/ProcessMonitor from SysInternals to check which call it is failing at or stuck at.
And a generic advice: starting UI from service in Windows is not the best practice. Services are created to do some background work and not to have user interaction. If you need UI for your service, better create UI that user start himself, of create a small app that will sit in tray and wait for an event from service and then start UI in user so called "window station".
Windows Server 2012 blocks all the files copied from other places. So I unblocked all the program files. Thanks for your help.
We have a automated printing service running as System account printing web urls.
The idea is using WebBrowser to load page and call Print upon it finished loading.
This works fine on Server 2003 , 2008r2 etc but does not work on Server 2012 ONLY IF it was running as a service. running as a console application works fine.
The problem:
It would load web pages fine and would call Print() , Print() will return but nothing gets printed on the default printer: no print job at all.
I thought it would be account problem so I tried to run service as the same logged on user but still does not work, if that user run application as console app then it would work fine. So default printer and user account get ruled out.
I don't think it is a code problem (it must be though) as it works for older Windows versions running as service.
It seems something fundamental got changed for a service process in server 2012.
Update １. It may relates to How do I print an HTML document from a web service?
However it works fine for me prior server 2012.
Update 2. It does not work even the whole print happens in a separate process, i.e. my service launches a process to do print, it does not work either. Everything works fine if I run same code in console mode. It is definitely not a threading problem but rather something deep in server 2012.
Now the questions are:
What is changed? Why it stopped working?
At http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/fdcfa0fa-50aa-4a61-be79-5b4c8f65fbf7/ we see that this was reported to Microsoft and confirmed as a bug in Windows 8 and Windows Server 2012.
This bug is triggered when trying to print from a 32bit process in non-standard user session (like e.g. a service).
According to Microsoft, this a bug was resolved in Windows 8.1 and Windows Server 2012 R2. However, we could still reproduce it on Windows 8.1.
On the same site, a workaround is given by Microsoft. This workaround solved the problem for us on Windows 8.1. It probably also works on Windows 8 and Windows Server 2012.
The workaround goes as follows:
Open Regedit and go to HKEY_CLASSES_ROOT\CLSID{BA7C0D29-81CA-4901-B450-634E20BB8C34}
Check the value of the "AppID" Registry Entry. In our case this was {AA0B85DA-FDDF-4272-8D1D-FF9B966D75B0}
Now go to HKEY_CLASSES_ROOT\AppID{AA0B85DA-FDDF-4272-8D1D-FF9B966D75B0} (or the respective value you found on your system)
Under this registry key, delete the entries with the name "AccessPermission", "LaunchPermission" and "RunAs"
Since this is a bug in Windows, you cannot fix it in your code. The workaround might have side effects, but we haven't seen any so far in our scenario.
I have a console application that performs some data work and then closes. If I run the executable manually it opens a command prompt, runs the program, and closes. No issues at all regardless of what Microsoft OS I'm using.
However, if I attempt to run the program as a scheduled task it fails on one specific server running Windows Server 2008 R2. It works as a scheduled task just fine on other servers, including another Windows Server 2008 R2 box in the same building. Unfortunately this one server is the server it needs to run on. I've tried adding logging, writing to the event logs, executing the application as an administration, forcing 32 or 64 bit, and launching it as a separate launch from a .bat file. Nothing. The program isn't crashing, it is just never opening.
Does anyone know what may be causing this? I'm at a loss and I don't know what to do.
Edit: I created a test .bat file that just launches a command prompt to see if it would open a command prompt window. It does not. The other tasks seem to run fine though.
Edit #2: I have been researched this and something that has come up is to set the task to enable with desktop. I can't find that option nor can I think of a reason why it would fix this issue but it seems to keep coming up.
After a bit of fiddling around this is what worked for me. When you point to the console application in the actions Tab, ensure that you fill in the 'Start in' field with the location where the executable is located even though it says that it is optional. Once you fill that in, it will work.