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.
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 have a TFDMoniFlatFileClientLink on a form, filename set to d:\temp\monitor.txt, tracing=true, TFDConnection.Params.MonitorBy=mbFlatFile. This sometimes works and sometimes does not trace anything. No file gets created.
Tested with Win7 32-bit app, with design time TFDConnection to either FireBird or Oracle. Delphi Tokyo 10.2.1
What is going on?
This was a really weird bug:
It turns out that the TFDMoniFlatFileClientLink remembers the filename when removed and placed back, then does not trace.
To reproduce:
Remove the TFDMoniFlatFileClientLink, optionally save the project, place a TFDMoniFlatFileClientLink on the form again, set tracing=true. It has magically remembered filename d:\temp\monitor.txt (where?), then either does not trace or traces to C:\Users\username\AppData\Local\Temp\traceX.txt.
Only when you change the filename does it successfully trace again.*
Similar weird things happen with TFDMoniRemoteFileClientLink, it very often does not create trace output for FDMonitor to pick up. I have not investigated the exact conditions under which this happens.
I found this in a test app after tracing the following issue, possibly related:**
A design time TFDConnection gets its parameters filled at run-time. I executed TFDConnection.Params.Add('MonitorBy=mbFlatFile') but the app did not trace. I verified that MonitorByInitial=true at run-time. Params.Add('MonitorBy=mbRemote') also failed.
A TFDMoniFlatFileClientLink and TFDMoniRemoteClientLink were placed on the datamodule at design time.
Reported in Embarcadero Quality Portal under issue RSP-19554
* Even if you change it to the same file name. If you do that at run-time you have to set Tracing=false/true around the FileName assignment.
** Mmm, not related. Reported as RSP-19559
Can someone explain me when Windows shows this message?
What do i have to do to stop my Program from throwing this exception?
I have a Delphi Windows Forms Program which throws this message short after doing some SQL operations.
So i do the SQL, everything seems fine at first, but at a random time after that windows is killing it by showing this message...
the intresting thing is, it only occours while debugging.
When i'm not debugging it's running perfectly stable.
EDIT: Using RAD-Studio2009
I dont want to turn off the message completely(Only hint i found by using Google)
i want to stop my program giving windows a Reason to do that.
Windows shows this message when an unhandled exception leaks out of your application. This is a fatal condition. Something very wrong has happened with your application because exceptions should all be caught.
You need to work out what is throwing the exception and why it is not being caught. The very first step is to expand the details of the error dialog and find out which module the fault is occurring in, what the fault is and so on. That should yield some high level clues at the very least.
Most likely the Delphi debugger will not be able to help you for such a fault. You need to configure your system to arrange for a crash dump to be produced by the Windows Error Reporting service. Then you can load up the error report in a tool like WinDbg and try to figure it out.
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?
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.