Conversion won't work with Excel


pdfcreator works with every document/program I use, Office Word works as well.
If i try to convert an excel file it just opens the program and it does nothing. It doesn’t even send the command to the virtual printer. I tried with Excel 2003 and 2010 (I have those two licenses). Any solution? Nobody seems to have posted the same problems. Permissions are all good.
Also, pdfcreator doesn’t seem to care about which is the default program to open file types. To switch between excel 2003 and 2010 I had to reinstall them every time, otherwise it just sticks to the last one installed even if you change the default programs in windows… a bug or a feature? Can this be controlled?

Windows 7.



unfortunately the way the “open with”, “print” and “print to” commands are registered isn’t the same for all Windows versions and it is very difficult for us to find a way to detect them properly from Win7 - Win 10, especially as this is very poorly documented. To find out what is wrong, please rung regedit.exe and look for the key HKEY_CLASSES_ROOT.xls (or the file type you are using with Excel, e.g xlsx). Check its “default” value and then go to HKEY_CLASSES_ROOT"the value"\Shell and copy the commands for “open” “print” and “print to” here.

If changing the default in Windows doesn’t overwrite those registry entries, PDFCreator will still keep on using the old ones.
Don’t hesitate to ask if you have any questions about this, it is a bit tricky.

Best regards,



Same problem here.

I find the following commands :

  • open: @%CommonProgramFiles%\Microsoft Shared\Office16\oregres.dll,-3
  • print: @%CommonProgramFiles%\Microsoft Shared\Office16\oregres.dll,-5
  • print to: undefined

What do I need to do now?




try using this command for print to:
"C:\Program Files (x86)\Microsoft Office\Root\Office16\EXCEL.EXE" /q "%1" /j "%2"

or @%CommonProgramFiles%\Microsoft Shared\Office16\EXCEL.EXE" /q "%1" /j "%2"
depending on the actual location of your Excel.exe

Best regards



Thank you for your help.

I used the following command : "C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE" /q "%1" /j "%2"

I have obtained the message: Sorry, we don't find PDFCreator.xlsx (I tried to convert an Excel file with a different name than "PDFCreator")



this is really strange, another user also had this issue; but I completely fail to understand why the command works properly here, but creates an issue elsewhere. Perhaps it somehow depends on the exact Excel version, which version does your Excel.exe have? Mine is 16.0.9330.2087.
Sorry for not being more specific, I haven't yet been able to find any official documentation on printing via command line switches inside office 2016. The command stored in your "open" and "print" keys seems to simply load the specified string(s) from the oregres.dll, it might somehow be possible to look inside the dll to find our which strings it is trying to use.

Best regards



No problem. My version of Excel is Excel 2016 MSO (16.0.4266.1001) 32 bits



Thanks for the feedback.
Does your environment allow to update Office to the latest version, or is this restricted?
Not sure if the different version is causing the difference, or the fact that I tested in an x64 environment and you are on x86. It might help to update to the latest Office version, if possible.


Sorry I can't update Office.

I have just tried to reinstall an older version of PDFCreator (version 2.5.3) and it's (strangely) working now.




the older version of PDFCreator call the .NET function for opening/printing the files, which can work in many cases, but can in some cases also causes PDFCreator to crash ( It reports there is an application to print / open the file, but there actually isn't, so when you call open or print on the file it crashes). In new versions we first try to read the command from the registry directly, which seems to be the most stable method of detecting print/open commands for file types. Unfortunately there still seems to be some cases in which this doesn't work properly either, but I am not sure how much we can fix/improve this without Microsoft fixing the .NET issue or properly documenting how to handle this issue for Win7-Win10.
Sorry for the trouble.

Best regards