I've encounter a situtation where frequently when debugging a ISAPI Dll (TWebModule) running under Apache I recieve errors. The caption around the error box is "Debugger Fault Notification" and included in the message is, amongst other things: "c:program filesApachebinhttpd.exe faulted with message......."
At these times the cpu window appears, and I must hit the "OK" button around the error message. I may need to do that three to five occasions before program flow continues.
This really is happening on my small laptop. I've got a desktop using the exact same configuration (so far as I understand) and that i do not have this issue. Both os's are XP. So clearly there's some setting or outdated file somewhere.
Also, I've observed if first run this site when Apache isn't within the debugging envrironment it appears not have this issue. (i.e. start apache within the services, run my web application, steer clear of the service, after which debug it inside the Delphi atmosphere).
Although it does not directly answer the how you can debug using Apache, another alternate debugging technique which is effective is by using idDebugger (near the foot of that page). It will help you to debug ISAPI DLL's from the IDE without needing to start/stop services. Now i never develop ISAPI DLL's without them.
To avert this along with other problems, I have began xxm. It's an alternative choice to TWebModule, and utilizes a separate wrapper to operate with IIS, there is however also an Apache, Opera and IE wrapper! Additionally, it uses mixed-HTML-Delphi-source and also the development-mode wrappers perform the parsing as well as an auto-compile to provide an internet-script-like atmosphere.
Even the InternetExplorer wordpress plugin is effective within the debugger (with iexplore.exe as host application).
Error code 0xC0000008 is
Status_Invalid_Handle. That may be tossed by
CloseHandle, for instance, whenever you attempt to close a handle that either never was open or had been closed. The mistake may not occur when you are running outdoors the debugger since the API will not throw the best unless of course it's being debugged.
If you are getting that exception in code the debugger does not get access to, then your debugger displays the CPU window rather. Consider the call stack to obtain the devote your code nearest to in which the exception originated from.
It is also entirely possible that it isn't occurring inside your code whatsoever. Try doing all of your same debug routine without your module installed. Would you get errors?