Already asked on the Evil Exchange, but as always that was no help. I'm having this problem today:
When creating a stand alone web application using IntraWeb, I get this exception in the IDE when I try to test out a session from my app in the browser:
First chance exception at $7C812A6B.
Exception class EOleSysError with
message 'CoInitialize has not been
called'. Process WebContactManager.exe
(1112)
If I click "continue" on the IDE exception dialog, the browser itself just shows:
200 OK
...rather than the controls on my main form.
This error does not seem to occur when I replace ADO with other database components such as dbExpress or BDE.
What is this error telling me, and how do I fix it?
(Note I'm using the stock "VCL for the Web" IntraWeb components which come built-in with D2007).
Thanks in advance for any and all help!
The "solution" provided in the link you quoted is basically wrong or at least incomplete. Only by setting ServerController.ComInitialization to ciMultiThreaded to true IW will gurantee that every thread will get COM initialized correctly. (for example think about Ajax callbacks)
If you create your own custom threads then you will have to call CoInitialize for that thread on your own though - as Intraweb does not know about your custom threads.
Just found an answer to this here:
I found a more elegant solution as the
whole problem originated from using
Intraweb, I rather get Intraweb to
initialise com for me. This sorts it
out nicely.
When using your MS SQL DbExpress
driver or ADO driver with Intraweb,
you must set the ComInitialization
property in the ServerController to
‘ciMultiThreaded’.
This will eliminates the "CoInitialize
has not been called" error.
Related
Found this this post ISAPI web application hanging if FastReport.PrepareReport is called
It helped solving my problem partially. As well I´ve turned Wisiyng property to False on frxRichView. Since I'm retunrnig a base 64 string I've also tryed switched loading from StrToStream/LoadFromStream to LoadFromFile. The problem persist with multiple acess, 2 out of 10 process can finish loading my Pdf file. All the others requests hangs until timeout. Does anyone have an idea what else can I do? is there anyother way to retunr rtf format into Fastreport report Thanks.
I could only get time-out error using Selenium to test multiples request from the client side.
Update: I've figured that just having a TfrxRichView component in the report causes the hanging, it doesn't even need to have a rtf text on it. Replacing it to a memo all request are answered.
UPDATE: Got a answer from fast report and I wold like your opinion.
ok,
I had similar problems, and it is not easy to find out the reason, but maybe you can find your solution in between my considerations..
1) Stack Size
When ran in IIS your ISAPI is only a DLL called by a process, you are not the main process so you have to pay attention to stack dimension.
Normally a Delphi application have a default stack size of 1Mb, in ISAPI DLL you will have only 256Kb of stack.
Maybe you are facing a stack overflow exception.. it can explain why it does not occurr always but only in some circumstances..
2) Trapped Exception
In general you get some error during the preparation of report (aka all the job of working with data, expressions, variables, formulas etc etc..) can bring to a trapped exception. You may be unable to see it from outside but code execution was broken somwhere and report preparation had not finished.
3) MessageBoxes and/or standard Exceptions
when running in ISAPI you should not output anything to user interface,
maybe a message dialog (or an exception) can bring to unexpected behaviour.
4) Global Var
You should avoid global var because in ISAPI they will be common across threads
So, if you have sources, debug the application.. at first exception you should understand where is your problem..
If you have not sources.. chek the above list.. I hope you can find some useful information.
You have two ways to solve this:
1- Try to recreate this behavior while debugging your ISAPI DLL. If you are lucky, you can identify the thread that is hanging your application. Sometimes this is hard or even impossible to recreate.
2- If you have access to the hung ISAPI application instance, use a tool like SysInternals Process Explorer to create a minidump file. Your application must be built using full debug symbols and you should have the corresponding map file. With one (or more - even better) dump files obtained from your hung application plus the map file, you can use another tool, WinDbg to analyze it and find the cause. (Sometimes) WinDbg can show exactly which thread is hanging the whole application and the line of code that causes it.
If you have never done that, I must warn you that this kind of analysis is almost a gamble... You have to use several different tools with little
or no documentation, read heaps of technical info in various places. In the end, sometimes it works wonderfully and sometimes it fails miserably.
Because debugging ISAPI is not obvious, but also because I wanted to be able to switch easily between more different hosting solutions — and wanted to update my website on the fly without a restart of the web-server/service — I created xxm. It has a singular interface to the HTTP context, your DLL gets loaded by either a IIS ISAPI handler, or a HTTP.SYS handler, or an Apache httpd module, or for debugging locally you can just set xxmHttp.exe as host application to get IIS out of the way.
I am trying to create a sample Delphi XE7 desktop app that will connect to SSRS 2005 web service but every time I try to call LoadReport web method, the following error is shown:
This is what I have done so far:
Create a desktop app.
Import WSDL for ReportExecution2005 and ReportService2005.
Create a button that call the web service based on the code shown
here. The web service locations as well as report are hardcoded for
simplicity purposes.
This is the code snippet from the link:
HTExec := tHttpRio.Create(nil);
rsExec := GetReportExecutionServiceSoap(False, ExecURL, HTExec);
// Load the selected report.
LRParams.Report := 'ReportName';
LoadParamsResponse := rsExec.LoadReport(LRParams); //here it fails
Note: I have already created a .NET win form app (VS2010 and VS2013) that consumes this web service without any issues, thus I know the web service and report to render are working OK. Sadly our requirements is for a Delphi solution, My educated guess is that the WSDL importer generated code is not correct and somebody out there may have come across with this issue before and know how to solve it.
I did a quick search for "http://schemas.microsoft.com/sqlserver/2005/06/30/reporting/reportingservices/LoadReport"
and found this.
If it applies to you as well, it may be the case you're calling the service on an incorrect URL, use the one with ReportExecution2005.asmxin it, not ReportService2005.asmx
(There's a lot more here)
To find out differences between the Delphi version and the working version, use a HTTP proxy (Fiddler2) to capture the SOAP HTTP traffic in both setups.
If you have no access to the working environment, use SoapUI to create SOAP requests.
We've recently setup out own webservice using SOAP and it all works like a charm.
Because the service is only used from within our own applications, I usually don't allow for a WSDL to be generated.
Today i started some tests with SoapUI and needed a WSDL of our own service. So I enabled the Default action of the TWSDLHTMLPublish component and tried to get the WSDL exported. All I got was an access violaton in WebServExp.GenerateXMLSchema, line 1636:
if (ParentInfo = nil) and ((GetTypeData(ATypeInfo).ParentInfo)^ <> nil) then
Debugging this, reveiled that GetTypeData(ATypeInfo).ParentInforeturned a nil, so of course using ^ on nil raises an access violation.
After removing the carret i had no problems generating the WSDL.
So did I find myself a bug here or am I missing something?
BTW: We have created our own SOAP.bpl, containing all original Delphi soap sources, to correct it for a known problem with exception derived from TRemotableException
So did I find myself a bug here or am I missing something?
Yes, that's a bug. And Subversion reveals it's been like that for many years - for as long as we've been on Subversion:(. [I am not setup to access the previous Starteam repository anymore].
I'm making to a note to remedy and check in unit tests for this. Please feel free to file a QC if time allows. And I'd like to hear more about the issue with TRemotableException-derived types.
Cheers,
Bruneau
I've multithreaded application where new TSQLConnection is created for each thread. If I try to use tracing (TSQLConnection.SetTraceEvent or TSQLMonitoring) I get the trace results as expected, but after that the main thread seems to beserk when I try to use any database functionality. Application throws excpetion "access violation at 0x004dffcf: write of address 0xfffffff2" and the call stack in IDE shows repeating lines of "7c90327a ntdll.RlConvertUlongToLargerInteger + 0x3c" and "7c90e48a ntdll.KiUserExceptionDispatcher + 0xe", and the top line is "Controls.ReadControlName(???)".
So, is the tracing function buggy and doesn't work with multithreaded application or is there hidden bug in my application? How to find out?
I'm using Delphi 2007.
Edit It looks like the exception is raised even with two separate connection in main thread. I'll try to create test application.
Problem solved, I had old (and apparently buggy) version of InterXpress driver loaded, I just didn't realize that it is part of the problem.
We have a Delphi 2007 COM component being executed from an ISAPI app. The COM component is hanging the app because it is attempting to display a MessageBox(). The call to MessageBox() must be occurring in the Delphi RTL becase it is not in our user code.
The app hangs, of course, because there is no one logged in at the server to clear the MessageBox().
How do we configure our Delphi project so that the Delphi RTL does not attempt to display MessageBox() on exception?
Write your own exception handler and attach it to the Application.OnException event. If an OnException event handler is present, Application won't use its default MessageBox routine. The signature is defined as:
TExceptionEvent = procedure (Sender: TObject; E: Exception) of object;
If this is a server, you'll probably want to write the exception information to a log, and possibly return some error to the user.
What does the messagebox say? I'm assuming it's an exception. Why don't you put an exception handler around the code in the COM component, and log the exception in a different way? (E.g., using the Event Log). And/or fix the problem that's leading to the exception in the first place.
I don't know of any direct way in Delphi but what you can do is write a small script in AutoIT/AutoHotKey and keep that script running in system tray, so that it will automatically close the MessageBox.
Believe me it is very simple.
http://www.autoitscript.com/autoit3/index.shtml
http://www.autohotkey.com/
HTH
Is it possible to compile the application as a Console app? I'm not sure if you can do this and still have it contain COM object, this would prevent message dialogs from being shown I'm sure.
Just a thought.
I've created a unit to hook MessageBox/MessageDlg calls (via detouring), so I can suppress these calls in a Windows Service (to avoid "hanging" of my service dll because of some stupid code of someone else with a messagebox call in it).
If you want it, I can search this unit and send it to you.