How can i debug CEF3 / libcef.dll in Delphi and collect info about c0000005 / 001dea9b exception

Question

I understand that my problem is multidimensional and I will probably get some independent advices, but thank you very much for all this and I am sorry if this is a newbie question.

I use a CEF (TChromium) browser in Delphi RAD 10. I regularly receive an error at the customer's production which I cannot replicate while working on the debugger. After displaying basic Win error information, the system (Win7) kills program, which ends with unsaved previous work. I checked each element of the code step by step, asked fellow programmers for analysis and it seems that this error applies only to the CEF browser. Every time, regardless of what i can manage to note in the program's work, the error is the same:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: MyApp.exe
  Application version:  0.0.0.0
  Application timestamp:    5e36d888
  Module name with error:   libcef.dll
  Module version with error:    3.2454.1344.0
  Module timestamp with error:  562d8f27
  Exception Code:   c0000005
  Exception Offset: 001dea9b
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:    1045
  Additional information 1: 0a9e
  Additional information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional information 3: 0a9e
  Additional information 4: 0a9e372d3b4ad19135b953a78882e789

Yes, I guess the problem may arise from a large number of different things, but I assume that since this only happens when using the browser (otherwise the program works perfectly), and every time the same problem is displayed, it may be a TChromium component.

Unfortunately, I was not able to understand what exactly causes this problem (libcef.dll c0000005 / 001dea9b exeption) and all threads found on various forums are terminated and/or unresolved.

I tried to program each page load by displaying a larger message instead of closing the program:

procedure LoadUrl(url: String);
begin
  try
  Form1.Chromium1.Load(url);
  except
    on E : Exception do
      ShowMessage('CEF: '+E.ClassName+' error raised, with message : '+E.Message);
  end;
end;

But when working on the debugger I do not get any error (again), and on production system just kills the application without any error message.

At first glance, I think I need an explanation:

• TChromium component actually changes only when i call it with "Load (url)", so do I understand correctly that this place in code is where I should focus?
• Can I program errors/exceptions of external libraries this way? Or maybe there is some other way to use them safely, so that the error will not be the reason for killing the app, but will be controlled on production?
• Will this mentioned procedure calling TChromium component give me more information than the system that kills my app? (Of course, if this is error place, because it seems to be the surest shot)
• I use the EurekaLog7 tool - but I can't understand how I should use it to track the browser library errors trace and where to call it, or even how to take it in code. Actually, I have absolutely no idea where to start using it on external library, I will gladly accept some documentation or a hint about what to read and where I will find an understandable example.

Thank you in advance and I apologize if this is too easy or a problem is stupid. Of course, I also know that since I do not provide the full code, it will be difficult to analyze the problem, but I want to learn such error analysis myself, so maybe you will forgive me. :)

~~Additional info

• program got x32 structure, is runned in win 7 xs64;
• program is a simple crawler whose task is to save selected elements of searched pages to a text file form;
• optional: it is enough for me, if this error manages to trigger my own shutdown procedure allowing to save the results simply, the app can be killed after because the sheduler will resurrect it;

Answer 1

Thanks to @J... i think i figured it out and here's solution.

The indicated error results only from the "work" of the libcef.dll library which (unfortunately) is probably no longer supported. Although this is not a problem solved anywhere - most indications of this error in various forums appear when there is a problem of referring to the wrong address in memory, and then following this lead is basically about out of memory error in various versions.

The libcef library has some fatal way of allocating memory and in itself leads to constant memory leaks. These leaks and misallocation quickly lead to the use of virtually all available memory... and it's easy to get a similar problem. First of all, adding a directive

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

after

uses WinApi.Windows

to the dpr form solves the problem for a while, because the program has more memory available and it takes longer to exhaust resources. This, of course, does not end the matter, because the suspension of the program will simply take longer.

But! It is enough when every few dozen scans (crawls) one will relocate memory for the form, which will automatically allocate memory, kills leaks - also in terms of the libcef library. I found and used such code that is called from time to time. It was enough for me to do what every 20 turns of the browser, but it may look different for everyone. You need to try trigger.

 procedure TrimAppMemorySize;
 var
   MainHandle : THandle;
 begin
   try
     MainHandle := OpenProcess(PROCESS_ALL_ACCESS, false, GetCurrentProcessID) ;
     SetProcessWorkingSetSize(MainHandle, $FFFFFFFF, $FFFFFFFF) ;
     CloseHandle(MainHandle) ;
   except
    on E : Exception do
     // inform me about problem 
   end;
   Application.ProcessMessages;
 end;

This is probably not the best solution, but it makes the unstable form with CEF3 stable and ready to work. For several days, working on several copies of the same form, no error appeared at all, so it can be a good solution maybe for everyone who has memory leaks with CEF3, has unknown errors similar to mine, or out of memory error caused by CEF3.

However - my question was how to debug libcef.dll and how to get more information about bugs of CEF3 library - and J... has finished the topic, thank you very much.

As for SalvadorDíazFau's offer - I really appreciate your involvement in the project, people like you are the foundation of our community; however, while CEF3 is still working it is less work for me than discovering new elements and possibilities of CEF4 which would require me to rebuild the form. There will be time for that. :)

Thank You Guys! Case closed already!