COM Object in WCF Service

3
votes

My WCF Service, written in .NET 4.0, has a problem that the second, or any other call get stuck. The WCF Service does nothing else than calling a COM Object written in Delphi XE. The threading model is set to Both, the InstanceContextMode of the service is set to PerCall. The object does not much more than BSTR DoRequest(BSTR Request). I use Marshal.ReleaseComObject, but read in an article this is not a good way to clean up com objects; i tried it also without.

I tried the following things:

  • added logging to see where the WCF service is stuck. It is inside the COM call.
  • added a unhandled exception handler, but there are no exceptions.
  • checked if the Delphi Object uses Static variables
  • tried to compile with Delphi XE2 (maybe a bug in the delphi com libraries)
  • tried the Object with a multithreaded Delphi stress test tool to see if the problem is the same, but it worked nicely.
  • tried the object with a C# console stress test tool and got the same behaviour as in the WCF Service.
  • added a lock object around creating the Object, doing the call and destroying the Object. This did not help.
  • tried to create a new thread inside the WCF and set the threading model to STA; set the Delphi Object Threading Model to Single. This did not help.
  • tried to run the Object in the COM+ Services; this did not help.
  • checked the WCF throttling, this is set to 100
  • checked max connections of the service and set to MaxInt

the COM DLL is 32 Bit, so my VStudio Project Settings restrict to x86. I run on Windows 2008 R2. Maybe this does matter: The Delphi COM Object loads a C++ DLL, which might not be treadsafe.

I used Reflector + Dennis Bauer FileDisassembler to decompile the generated COM Wrapper. I dont see any special in it.

Using Windebug seems not very easy, as Delphi does not support PDB Files.

running out of ideas, please help :-)

1
c#wcfdelphicomcom-interop
Did you try to call a dummy COM class from within your service just to properly locate the issue? If the WCF you wrote works with the dummy COM, then your Delphi COM class is a culprit. Try to mimic the settings (32bit, calling another C++ DLL etc.) – Wiktor Zychla
I gonna rewrite the minimum part of the delphi com in c++, but i hoped someone shouts out have you thaught about this attribute or something simple :-) – NickD
You have to debug that delphi code. If you log the parameters you're using to call when it freezes, you can load that DLL and call it from a test delphi application with the same parameters and that will help you debug with COM and such out of the picture. But you're going to need Delphi, the DLL's source code, and the parameter values that make it crash, and then you're going to have to debug that code yourself. – Warren P
@Warren, did this already. And guess what it works, even when it's multitheaded, see in my comments above. – NickD
I think it has to do with a WCF Setting or something with the Marshaling. It does not even throw any exception, it just gets stuck like if all worker threads of the WCF are blocked by a dangling object. – NickD

1 Answers

2
votes

I added a critical section around all calls to the third party dll inside the delphi code. It looks like it is working now. This does not explain the behaviour of the com object, but now it seems to work.