I wanted to debug a data module that I've created and which is a part of a DLL, but for some reasons, I can't debug it. The debugger doesn't seems to be hitting the break point, is there a way i can debug my Dll/ data module.
Check list:
be sure your DLL have included debug info
if it's COM DLL - be sure it is registered on same place where you build it
try to rebuild the DLL, rebuild the App if you have changed the interface
check in EventLog when debugger loads the DLL does it says it have or dont have debug info.
To debug the DLL, the project loaded in Delphi must be the DLL itself. You enter a host application (Your application server executable), the one which will load the DLL. Make sure the host application load the DLL exactly where you have built it. You cannot move the DLL once constructed.
If the DLL must be in some fixed place, be sure to set the DLL's project options so that the DLL is produced at the right place.
And of course you must activate the debug build configuration for the DLL.
Using a tool such as ProcessExplorer (https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer), you can see if the DLL you built was actually the one loaded by your application server.
Related
Please help me with this problem.
This problem comes when I move my project to another PC. This program works fine on my PC.
You have your project configured to compile with Runtime Packages enabled. That means for any standard, 3rd party, and custom packages that your project uses, you have to deploy their respective BPL files that your EXE depends on, in addition to the EXE itself.
A BPL is just a fancy DLL with built-in support for Delphi’s RTL and VCL/FMX frameworks. The error you are getting is a standard Windows error popup dialog when the OS loader can’t find a required DLL that an EXE is statically linked to.
To avoid the error, you need to either:
deploy all required BPL file(s) along with your EXE. Use a tool like Dependency Walker to figure out what they are.
turn off the “Runtime Packages” option. Your EXE will be much larger, but it will be more self-contained, as the relevant package code will be built into the EXE itself.
problem description :
..... ( this code is executed inside a thread.execute
...
if fileexists(myFile) then
begin
// call functions inside a DLL
...
dll_process_data ( .....) ;
....
end;
..... (clean up )
write_clean_data_fct(...)
..... //
... // AV happens here inside kernel.dll , no further information
If the file is not found the complete routine / multithreaded algos is executed without any problem; If i add the additional files some data is processed inside a dll, this is also done without trouble.
Somewhere after the write_clean_data_fct the AV happens now. INside the dll I open a file read data and do data processing with these data.
Q: what might be the reasin and how to debugg this issue ??
Can#t post more lines of code because the complete code sequence is ~ 15.000 LOC.
You can debug the DLL like this:
Open the DLL project in your IDE.
Make sure the host is going to load the DLL from the same path as your DLL project's output directory.
Set a break point on the function you wish to debug.
From the menu select Run | Host application and specify the host executable.
Run.
You should now be able to debug code in the DLL. In modern versions of Delphi, you should also be able to step into the DLL code when debugging the host executable. This requires you to have built the DLL with debug information, and for the host executable to load the DLL from the DLL project's output path.
Your actual problem sounds a little tricky. The access violation perhaps occurs long after the erroneous code executes. To debug that, you might first identify the code that raises the exception. Which part of that code has a pointer that could be invalid? Then track back to anything in the DLL that could have modified that pointer.
If static analysis does not help then you can add debugging tools. You'll want:
Range checking enabled to detect obvious buffer overruns.
Full FastMM debug to detect heap corruptions, access after free etc.
madExcept to give detailed diagnostics and stack traces for the actual exception.
You'll want these tools in all modules.
I have EXE and 2 DLL used by this EXE. All binary were compiled by Delphi XE2.
How to debug 2 DLL at one time while running EXE?
The second IDE can't attach to the process what is under debugging by the first IDE.
In fact you don't need to do anything special for this to work. You don't need to run multiple IDEs and you don't need to attach to processes. Start debugging your executable and simply step into the code in the DLLs. The debugger takes care of it all for you.
I have solved debugger issue by the following steps:
Open any source file of each of two DLLs.
Add any breakpoint to each of two DLLs (maybe optional step).
Run host application on one of two DLLs.
I have a problem which I do not understand. I am using a DLL in my application. This DLL requires other DLL's and I have all of them. If I put the libraries in my appliction folder everything works fine.
However, having a bunch of DLLs in application folder looks quite ugly so I wanted to move them to application\lib subfolder.
After this change now I am getting External Exception when I try to use some of its functions.
I've only changed one line of code:
The original code
DLLHandle := LoadLibrary(Pchar(ExtractFilePath(ParamStr(0)) + 'External.dll'))
The code after change
DLLHandle := LoadLibrary(Pchar(ExtractFilePath(ParamStr(0)) + 'lib\External.dll'))
In both cases DLLHandle have a handle after loading the library. I am also not getting any error after calling GetProcAddress( DLLHandle, '_SomeFunction#8')
No exceptions, and return value of GetLastError is always 0.
Do you have any idea what could be wrong?
Thanks.
Life is far easier if you keep the DLLs in the same folder as the executable. That's the first folder searched when libraries are loaded. To move all the DLLs into a sub folder of the executable directory requires cooperation from all DLLs.
Most likely you have secondary DLL dependencies that are not cooperating. So exe loads A fine, but then A fails to load B. You can debug this further with Dependency Walker running in profile mode. It's quite possible that a secondary DLL is being loaded with implicit linking and that this throws and exception. Whatever the cause, Depenency Walker will lead you to the problem.
Whilst you can modify the PATH variable this is generally not advisable. If you do choose to go down this route then don't modify system wide, just modify the executable process environment at runtime before the first LoadLibrary. This is tenable so long as all your DLL linking is explicit using GetProcAddress.
All accepted wisdom recommends that you put your DLLs in the same folder as your executable. I would echo this recommendation. If you did this then you would be able to use implicit linking which would greatly simplify your code.
Yet another option may be to abandon DLLs and link everything straight into your executable. Unless you have a plugin type architecture, a single big exe is by far the simplest approach.
The other DLL's that need to be loaded must be on the system path for Windows to find them. Your application can find the External.dll as you explicitly define the path. Try adding the lib folder to your system path.
I try to debug a COM dll (TAutoObject) in Delphi and my break point are not green.
I put my option like this :
host : c:\Program Files\Internet
Explorer\iexplore.exe
param : c:\software\test.html
My test is well lanched but no breakpoint in Delphi
what is the way to to this ?
You have to run the program which launches the COM+ object and then attach it to the process.
IE launches a sub-process which hosts non-trusted code. this is probably why your debugging settings are not working, and why attaching to the process once launched works.
Since the debugger doesn't start the file, that won't work.
IIRC you can try to "attach to process" to the process running it (iexplorer.exe), but the problem is that that doesn't allow to debug through the start of the component. (since it costs time to manually attach)
I had a different setup where I instantiated a very slightly differently compiled .ocx on a panel of a delphi app, and used that to debug. Which worked fine.d
This link Breakpoint not honored while debugging a DLL helped me debug my com dll in Delphi 5. Go to Project -> Options -> Linker -> check mark "Include remote debug symbols". I couldn't tell you why it worked. Delphi 5's help provided the following description:
Include remote debug symbols Check this if you are using remote debugging.
You also need to have integrated debugging turned on. Its on the general tab of the debugger options.
In the past what I have done is to create a separate program which invoked my COM object and used it as the target for debugging rather than the standard host. This simplifies things and also allows you to create specific repeatable tests of known issues to aid in smoke testing later.
you can also use tools like CodeSite.