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?
Related
I'm out of my wits. I'm trying to set up remote debugging of lua code in dockerized openresty. I use PHPStorm with EmmyLua extension, and the mobdebug library on the Lua end. I have been reading and hearing reports of this working for people, but for me stopping on a breakpoint (or immediately after mobdebug.start()) works about 15% of the time (evidence that I am not completely misconfiguring the thing), including exactly 0% of those places in my code that I actually want to debug.
I will not be debugging this issue. I intend to work around it by using an exact setup that is known to work, so I need someone for whom it does work to tell me what their setup is:
OS version
openresty version
mobdebug version
any custom patches or hacks you might have applied to get the debugging working
luasocket version (probably relevant)
PHPStorm version
EmmyLua version
docker and docker-compose version, if applicable
whatever you may suspect to be relevant
I am willing to completely raze my development environment and rebuild it exactly to the working spec, just to have working Lua debugging.
EDIT: for those interested, here are my detailed symptoms:
I can't stop at actual breakpoints, ever (i.e. after I initially stop after mobdebug.start() and then "Resume program" and a line with a breakpoint is hit, but it doesn't stop there)
I can stop after mobdebug.start() in code executed from init_by_lua_block, i.e. once per server start / config reload
I can't stop after mobdebug.start() in any code executed during handling a request, i.e. ssl_certificate_by_lua_block, rewrite_by_lua_block etc. This is probably understandable because coroutines are involved
All my attempts at enabling coroutine debugging in request handling code either error out or have no effect:
mobdebug.coro() in init_worker_by_lua_block() errors out with "API disabled in current context" somewhere in mobdebug.lua
mobdebug.on() in the function I want to debug either has no effect, or errors out with "attempt to yield across C-call boundary"; I haven't discerned the pattern yet.
stopping on a breakpoint (or immediately after mobdebug.start()) works about 15% of the time
Stopping after mobdebug.start() should work under all circumstances, except when there is a connection already established to the same debugger controller, so the fact that it doesn't usually points to the system that tries to establish multiple debugging sessions to the same controller/IDE (or no connection can be established at all).
Similarly, there are several reasons why breakpoints may not be working, but if they work in a file as part of a specific setup, then I'd expect them to always work in that case. Some of the reasons why breakpoints may not be working are listed in the documentation: https://studio.zerobrane.com/doc-faq#why-breakpoints-are-not-triggered.
mobdebug provides a command line-based controller, so for troubleshooting purposes it may be easier to use that instead of a more complex setup.
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 following the steps in this article for attaching WinDbg to IIS to find the root cause of an "External component has thrown an exception" error. I am using WinDbg 10 (from Windows 10 SDK) on a Windows 7 on an ASP.NET MVC .NET 4.6 (Visual Studio 2015) app. When I attach WindDbg to the w3wp.exe process, reload the web page, the browser just spins waiting for a response. As soon as I stop WinDbg, the response is received. Looks like WinDbg is stalling IIS for some reason. I have checked/unchecked the 'invasive' checkbox. I enabled/disabled CLR Exceptions. I am not professient in WinDbg.
Any ideas what might be the issue? Or other quick way to troubleshoot that kind of exception? I usually know the issue is a compile error in a partial view after spending some time but I am interested in learning WinDbg's way of finding it (if it can).
Attaching WinDbg will cause all threads to suspend. If that is the case, your command prompt looks like this, waiting for input:
At this time, if I understand the purpose of the linked article, you should enter things like
.symfix;.reload
.sxe clr
.loadby sos clr;.loadby sos mscorwks
To resume the threads and continue execution of the program, enter g. After that, the command prompt should change to
Now do something in your application and wait for an exception, then issue the commands mentioned in the article
!dumpheap -type CompilerError
!dumpobject <0xXXXX>
or (I would suggest)
!pe
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...
I have a windows service that is failing to start, giving an error "Error 1053: The service did not respond to the start or control request in a timely fashion".
Running the service in my debugger works fine, and if I double click on the the service .exe on the remote machine a console window pops up and continues to run without problem - I can even see log messages showing me that the program is processing everything the way it should be.
The service had been running fine previously, though this is my first time, personally, trying to deploy it with the most recent changes made to the program. I've evaluated those changes and cant figure out how they might cause this problem, particuarly since everything runs fine when not started as a service.
The StartRoutine() method of the service impelmentation is empty, so should be returning in a "timely fashion".
I've checked the event logs on the computer, and it doesn't give any additional information other than it didn't hear back from the service in the 30 second requisite time frame.
Since it works on my machine, and as a double-clicked executable, how would I go about figuring out why it fails as a service?
Oh, and it's .NET 2.0, so it shouldn't be affected by the 1.1 framework bug that exhibited this symptom (http://support.microsoft.com/kb/839174)
The box is a windows server 2003 R2 machine running SP2.
This is a misleading error. It's probably an unhandled exception.
Empty your OnStart() handler then try this in your constructor...
public MainService()
{
InitializeComponent();
try
{
// All your initialization code goes here.
// For instance, my exception was caused by the lack of registry permissions
;
}
catch (Exception ex)
{
EventLog.WriteEntry("Application", ex.ToString(), EventLogEntryType.Error);
}
}
Now check the EventLog on your system for your Application Error.
Could be a number of things and it might help to get a stack trace on the machine exhibiting the problem. There are a number of ways to do this but the point is that you have to see where this is failing in the code.
You can do this with remote debugging, but a simple thing might be to just log to the event logger, or file log if you have that. Literally, putting "WriteLine("At class::function()") throughout portions of the code to see if you've made it there.
This will at least get you looking in the right direction (which ultimately is the code).
Update:
See Microsoft's How to Debug Windows Services article for details in troubleshooting startup problems using WinDbg.
This related question details nice ways to debug services that are written in .NET.
I agree with Scott, the easiest way to find out what's happening is to put some traces in the start-up code (maybe it doesn't even come to your start-up code).
If this doesn't help, you can post your code here so others can take a look.
perhaps lacking some dependence, try this :
- deregister your service
- register again
If fail at register means that lack an module.
If the StartRoutine is empty, you are probably starting it somewhere else.
IIRC you need to fire off a worker thread, and then return from StartRoutine.
One of the problems which may lead to this error is if windows service which needs to be deployed consists of some error i.e it may be simple authorization error or anything as in my case I have referenced some folders and files for logging which were not existing, but when provided the right path of those file and folders it solved my problem.
I ran through every post on this particular subject and none of the responses solved the problem, so I'm adding this response in case this helps someone else. Admittedly this only applies to a new service, not this specific case.
I was writing a File listening service. As a console app, it worked perfectly. When I ran it as a service, I got the same error as above. What I didn't know (and many of the MSDN articles about services conveniently leave out) is that you need to have your class executed from within ServiceBase.Run( YourClassName());. Otherwise, your app executes and immediately terminates and because it terminated, you get the error above even if no error or exception occurred. Here is a link to an article about this. It actually discusses setting up your app for dual use - Console app and service: Create a combo command line / Windows service app
I had that issue and the source of my problem was config file. I edited it in notepad and notepad added one special character which cause service not to run properly because config file was ruined. I saw that special character in notepadd++ and after delete it, service started to run successfully as previous did.
In my case, the correct .NET framework was not installed on the server that I was installing the Windows service on.
One other reason is If you copy the DLL in 'debug' mode to installation folder this issue will come.What you need to do is Run the project in 'Release' mode copy the DLL or directly form Release folder rather than Debug folder,,and copy that DLL in to installation folder,it will work.You can see the reduction in size of DLL ,it will not contain any debug symbols and like that