I have an addin that is written in Delphi XE3/XE4, using the Add-in-Express framework (i.e. not .NET, no VSTO). It is running fine in all 32bit-versions of Outlook as well as the 64bit-version of Outlook 2013. However, under the 64bit-version of Outlook 2010 it simply will not load: The COM-Addin manager tells me "Not loaded. A runtime error occurred during the loading of the COM-Add-in." (i.e. the LoadBehavior-value in the registry got set to 2).
Is there any way to find out what that "runtime error" might be?
I have already put OutputDebugStrings all over my code as well as the VCL and ADX code and not a single one of those appears to ever be reached at all before Outlook unloads the DLL again.
When running in the debugger (via PAServer) any breakpoints I set (e.g. on the begin of the DPR-file or in the initialization of the Classes unit) do not even ever get enabled. Seems to me the DLL is never even loaded into the debugger (this does work fine with Outlook 2013x64).
I also already wrote a dummy host EXE that would instantiate my COM server and call the appropriate methods on the IDTExtensibility2-interface to simulate the actual Outlook host but no errors occur in that case either.
Looking at things with Process Monitor, the addin DLL gets loaded briefly but then immediately gets unloaded again and then the LoadBehavior value is reset.
I checked the Application logs and enabled logging in Outlook itself but so far no hints to the nature of the supposed "runtime error".
All latest updates and service packs were applied to all of Delphi, Add-in-Express, Outlook, Windows. The Windows version is 7 Pro. No other addins are installed.
Any more ideas on what to check?
Add an environment variable VSTO_SUPPRESSDISPLAYALERTS value 0 to that PC that is causing the problem.
Then u can reload the addin from outlook >> options >> Addins >> Manage.
So outlook will try reloading this addin and u will get a popup window with details of the prob...
Related
It's a Delphi XE2 app. Pretty simple. Just calls CreateOleObject('Outlook.Application') and assigns the result to a Variant.
If the program is run as administrator it fails with "Server execution failed", but it works fine and I can get the version number back if I run as the logged in user (without elevated permissions).
Why is this? What is it about running as administrator that stops it from creating the object?
This error is due to a mismatch between the security contexts. Outlook is a singleton, so CreateOleObject will connect to the running instance of Outlook if it is available. COM system refuses to marshal calls between processes with different security contexts.
Either make sure Outlook is not running when calling CreateOleObject or make sure both processes run in the same security context.
You can also switch to Extended MAPI (which is a set of dlls loaded in-proc) used directly or through a wrapper (such as Redemption (I am its author) - its RDO family of objects roughly corresponds to the Namespace object in the Outlook Object Model.).
I've written a server in Delphi 2010 that needs to launch a console application every now and again to back up a database. The console application can send log information to the console window, but it is not required.
This works fine when running as an application, but when run as a service I get an access violation when launching the console application. This is the case even if I launch it hidden (SW_HIDE).
Is it possible to launch a hidden console application from a Windows service? The solution needs to work on XP, Vista and Windows 7.
EDIT: The access violation happens when I call ShellExecute.
If you are using ShellExecute, then don't: it won't work inside a service, and is almost never the best way to start a process.
Use CreateProcess in stead.
See this bunch of ShellExecute / CreateProcess question threads on stackoverflow.
--jeroen
I have created a Delphi Service which prints TQuickReports. Everything works fine if compiled and run as a Windows Application. But when converted to operate as a service trying to create a form containing a TQuickRep component throws the exception.
This service runs fine on many other boxes but not this one in particular. Here are some details:
Using QuickReport version 4.07
Box is a Windows Server 2008 operating system.
Using Delphi 2007
Printer.Printers.Count is returning a positive value. In fact I can list out all of the printers.
I have tried running the service both using Local System Account and Logged on as an Admin.
Is there a default printer set up in session 0? Remember that under Vista / Server 2008 / Windows 7, services run in a separate session. Whether or not the logged-in user has a default printer set is not relevant - it's a per-session setting and doesn't affect session 0.
Can you rewrite the code to gracefully handle that exception and pick a printer to use?
You can solve this problem by creating a new dword UserSelectedDefault with the value: 1 in
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices\Session_ID
Make sure you have a local printer selected.
You might give the user a way to select the printer for the service. The Windows service probably does not have a default printer set.
Set TQuickRep.PrinterSettings.PrinterIndex to set the printer number. Then, TQuickRep.Print to print the report.
A colleague ended up finding the solution. I should have added these are "network" printers and not Local printers (at the time I didn't think this was related to the problem). So the service needed to be installed with "NetworkService" as the user account under the logon tab. From the Windows Help:
To specify that the service uses the Network Service account, click This account, and
then type NT AUTHORITY\NetworkService
We had a simular problem here. Using TS servers, Citrix and Powerfuse 9.
Powerfuse had all printers capitalized, however they were shared in a mixed case.
This combination caused Delphi/QReport to crash
When all printers are from printserver to powerfuse in the same case (not important upper or lower or even mixed), the problem was gone
Actually it is a Delphi(5) problem. The comparison of the available printers and the default printer is case sensitive (Printers.pas):
if TPrinterDevice(Objects[I]).Device = Device then
begin
with TPrinterDevice(Objects[I]) do
SetPrinter(PChar(Device), PChar(Driver), PChar(Port), 0);
Exit;
end;
Changing the comparison to:
if lowercase(TPrinterDevice(Objects[I]).Device) = lowercase(Device)
solves the problem.
If using terminal services 2008, same user for multiple sessions, you should look into the:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices\Session_ID
instead of
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\
I solved a similar problem: If a Delphi application (or service) uses QuickReport, it runs before the system loads the default printer (or printers).
When QuickReport executes TQRPrinter.Init, the printer.printers.count is zero,
shortly after the system loads, the printer.printers.count is the number of printers,
but tqrprinter.int has already executed, so TQRPrinter.FPrinterOK is false,
you then see this error when you try open a QuickReport.
The solution for me was wait until the printers were loaded before launching the application (in citrix and terminal server). I solved this in two ways, either by overwriting tqrprinter or delay the dpr.
Earlier today we experienced a YSOD on one of our MVC sites running on IIS on Windows Server 2003.
Usually, these are reported via e-mail using ELMAH (using this setup), but since this was a compilation issue (of some sort), it did not get reported via e-mail.
The specific error was:
"The directory 'App_GlobalResources'
is not allowed because the application
is precompiled."
This is a major problem, since a potential customer could notice the problem before we do. How can we make sure these YSODs are logged, when the exception handler on the site is not called?
It is possible to monitor the event log with VBScript. You could then email this when it occurs:
Here's an example:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/feb07/hey0226.mspx
and email from vbscript:
http://www.paulsadowski.com/WSH/cdo.htm
You could do this with powershell and/or another .net app on the box also.
If you can, check the event viewer on that machine. This is the logger of last resort on a Windows machine.
I have run into a situtation where frequently when debugging a ISAPI Dll (TWebModule) running under Apache I get errors. The caption on the error box is "Debugger Fault Notification" and contained in the message is, among other things:
"c:\program files\Apache\bin\httpd.exe faulted with message......."
When this happens the cpu window pops up, and I have to hit the "OK" button on the error message. I might have to do this 3 - 5 times before program flow continues.
This is happening on my laptop. I have a desktop with the same exact configuration (as far as I know) and I don't have this problem. Both operating systems are XP. So obviously there is some setting or outdated file somewhere.
Also, I have noticed if first run my website when Apache is not in the debugging envrironment it seems not to have this problem. (i.e. start apache in the services, run my web app, stop the service, and then debug it within the Delphi environment).
Any ideas???
While it doesn't directly answer the how to debug using Apache, another alternate debugging technique which works well is to use idDebugger (near the bottom of that page). It will allow you to debug ISAPI DLL's directly from the IDE without having to start/stop services. I now never develop ISAPI DLL's without it.
To avoid this and other problems, I've started xxm. It's an alternative to TWebModule, and uses a separate wrapper to run with IIS, but there's also an Apache, FireFox and IE wrapper! It also uses mixed-HTML-Delphi-source and the development-mode wrappers do the parsing and an auto-compile to give a web-script-like environment.
Also the InternetExplorer plugin works great in the debugger (with iexplore.exe as host application).
Error code 0xC0000008 is Status_Invalid_Handle. That can be thrown by CloseHandle, for example, when you try to close a handle that either was never open or was already closed. The error might not occur when you're running outside the debugger because the API won't throw an exception unless it's being debugged.
If you're getting that exception in code that the debugger doesn't have access to, then the debugger will display the CPU window instead. Look at the call stack to find the place in your code closest to where the exception came from.
It's also possible that it's not occurring in your code at all. Try doing your same debug routine without your module installed. Do you still get errors?