Unfortunately, I am stuck again. What worked quite well yesterday, doesn't work any longer today. I suspect I got a deadlock somewhere, and thus my breakpoints are never reached.
What's happening is that I can start my service, get a PID, and attach the debugger using "run - attach to program", and then the debugger breaks in "ntdll!DbgBreakPoint", From there I can use "Run (F9)" to continue. Unfortunately this is where success ends, no further breakpoint is ever hit. I suspect that my daemon may hang somewhere, but I cannot find out where.
At the core of the problem lies, the the PID gets known only after the daemon has been started, and there won't be any way to let it hit a breakpont on start, because I cannot find out the PID and attach the debugger before all the onStart code has already executed.
Two possible soutions come to my mind, but each arises a bunch of further questions I do not yet have answers for:
- there could probably be a construct DebuggerAttached.waitfor() to tell the code to wait, until the debugger is attached. I could put this into the onStart method, maybe. Does such a possibility exist?
- I could try to run the code from normal lazarus in user context, I suspect the problem is not at all related to background operations, and then somehow trigger OnStart just like the OS service manager does. I did always suspect that this could be the functionality behind the -run command line parameter. So I put a breakpoint into onStart, and set the command line param string in Lazarus to -run. Nothing happened, the program started and ended immedately, without doing anything. Is there any way to achieve what I want? What is the functionality behind the -run parameter?
Thnx, Armin.