Debugging multiple DLLs simultaneously

[Neutral General 15]

Hello,

 

I've got an application which dynamically loads multiple DLLs from my project group.

All those DLLs are exposing a small API they use to communicate with each other (and the exe).

Debugging what happens inside a DLL isn't a problem. I can just attach the debugger to the process and it works.

But what do I do if I'm in a debugging session in foo.dll with a break point on an API function calling code in bar.dll

I would like to step into this function but I don't really know how I could do that. 

My first plan was to stop at a breakpoint on the call, detach the debugger, switch projects and reattach it to bar.dll so I can debug the inside of the call.

But as soon as I detach the debugger, the process just continues execution. 

 

Does anyone know a good solution to this?

Edited December 18, 2018 by Neutral General

[dummzeuch 1505]

Brute force method: Add a MessageBox call instead of a breakpoint, so the program will stop and wait for you to attach.

[Neutral General 15]

That's not the reply I was hoping for but I guess there's no better way to do it 😞

[dummzeuch 1505]

2 hours ago, Neutral General said:

That's not the reply I was hoping for but I guess there's no better way to do it 😞

There might be a better way, I just don't know it.

[TiGü 21]

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}


uses
  System.SysUtils,
  Winapi.Windows;

procedure Main;
var
  I: Integer;
begin
  Writeln('Start');

  while not IsDebuggerPresent do
  begin
    Writeln('I''m waiting for you!');
    Sleep(100);
  end;

  for I := 1 to 1000 do
    Writeln(' I:', I);

  Writeln('End');
end;

begin
  try
    Main;
    Readln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

end.

Try the good old While-Not-IsDebuggerPresent-Trick! 

Edited December 19, 2018 by TiGü

[Neutral General 15]

Thanks! 🙂

That's still not the holy grail but a lot better than a message box. 👍

[David Heffernan 2345]

Build a monolithic executable and then the problems disappear. 

[TiGü 21]

14 hours ago, David Heffernan said:

Build a monolithic executable and then the problems disappear. 

I guess it will have a good reason/requirement why he needs to use an application with multiple DLLs. 

[Sherlock 663]

14 hours ago, David Heffernan said:

Build a monolithic executable and then the problems disappear.  

Considering you'll have to compile all the DLLs with every new release anyway in order to avoid at least part of DLL-Hell I fullheartedly agree. Furthermore DLLs are quite a security issue:
https://www.youtube.com/watch?v=HVigruKph74

 

[Neutral General 15]

17 minutes ago, Sherlock said:

Considering you'll have to compile all the DLLs with every new release anyway in order to avoid at least part of DLL-Hell I fullheartedly agree. Furthermore DLLs are quite a security issue:
https://www.youtube.com/watch?v=HVigruKph74

 

I've got an application (windows service) that (in the best case) shouldn't be shutdown ever. But there are going to be updates to the application. So in order to not have to shut down the whole service, the service is modular and can just temporary unload a DLL, update and then reload it. That's not really doable with a monolithic application.

[Sherlock 663]

40 minutes ago, Neutral General said:

But there are going to be updates to the application. So in order to not have to shut down the whole service, the service is modular and can just temporary unload a DLL, update and then reload it.

It is always good to try and be better than the hosting OS, and if the service is that vital, I'm sure you made risk assessments leading to counter measures for DLL-injection and the overall adverse effects of DLL-Hell. If you did it just because you could...I strongly advise to reconsider.

 

But we are drifting away from the topic. Sorry for that.

[David Heffernan 2345]

4 hours ago, Neutral General said:

I've got an application (windows service) that (in the best case) shouldn't be shutdown ever. But there are going to be updates to the application. So in order to not have to shut down the whole service, the service is modular and can just temporary unload a DLL, update and then reload it. That's not really doable with a monolithic application.

It will be shutdown when the OS updates. Also, if you want to make it hot upgradeable, make a monlotihic DLL hosted in a thin executable.