Access violation installing a component

[Dave Craggs 7]

I have a component (bpl) I am trying to install. I have installed this successfully on Delphi 12 on my notebook but on my desktop I get

 

 

 

It builds fine but when you select install  you get the access violation

 

 

How can you debug this sort of thing?

 

Dave Craggs

Edited May 21 by Dave Craggs

[Lajos Juhász 293]

Select the package and from the main menu activate  Run - Parameters. For host application you shoulds select bds.exe (default location is C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\bds.exe).

 

Hit F9 a second instance of Delphi will start in that instance open the package and try to install. You should get a call stack. 

[JonRobertson 72]

Installing the package will require Delphi to call Register. I doubt that Delphi calls Register every time it loads a package.

 

@Dave Craggs Since you are building, do you have source for all of the components in the package? You could add OutputDebugString logging to the Register procedure as a start, to narrow down the component causing the AV.

[JonRobertson 72]

2 minutes ago, JonRobertson said:

Installing the package will require Delphi to call Register. I doubt that Delphi calls Register every time it loads a package.

You could try an alternative to Lajos' suggestion. Manually launch a second instance of Delphi, and then use Run->Attach to Process to attach to the first. You will want to check Task Manager before launching the second instance, to get the PID of the first. You will see both instances in the Attach to Process dialog.

[Anders Melander 1795]

40 minutes ago, JonRobertson said:

You will want to check Task Manager before launching the second instance, to get the PID of the first. You will see both instances in the Attach to Process dialog.

That's not necessary; The attach dialog doesn't allow you to attach an instance to itself:

[Dave Craggs 7]

12 hours ago, Lajos Juhász said:

Select the package and from the main menu activate  Run - Parameters. For host application you shoulds select bds.exe (default location is C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\bds.exe).

 

Hit F9 a second instance of Delphi will start in that instance open the package and try to install. You should get a call stack. 

Did that - when you say open up the package do you mean open up the project again and run install? Did that and both instances of d12 crashed.

 

I do have the source.

[Dave Craggs 7]

This also describes the process https://stackoverflow.com/questions/62969608/debugging-a-package-during-component-installation

 

But both instances of Delphi just disappear! 

[Lajos Juhász 293]

25 minutes ago, Dave Craggs said:

But both instances of Delphi just disappear! 

 

 The first instance of bds should debug the second one. Thus, it should break on the error and show the call stack. 

 

The last Delphi version where I have had problems that required to debug a second instance of Delphi was XE5. In Delphi 12 I compile without runtime packages and have a limited of debugging this kind of errors.

[msohn 28]

49 minutes ago, Dave Craggs said:

But both instances of Delphi just disappear! 

A process (and its children) just disappearing without any further error message, typically indicates a stack overflow (from my experience, I'm not aware of other causes).

 

Did you check Windows event log? The crash should definitely be logged there. Maybe it contains a pointer on what the cause was.

 

Did you try setting an as-early-as-possible breakpoint in the loaded package(s). I.e. initialization section of the dpk or a unit. You'd hope you can stop it before the crash occurs.

 

Since you mentioned it worked on another machine: maybe some external references (DLLs etc) are missing? Normally that would just prevent it from loading and not cause such a crash. But I've seen DLLs reacting very strange if in-turn they had missing dependencies (e.g. VC++ runtime missing).

[Dave Craggs 7]

This is strange

 

Got these from the event log

 

 

 

This is Delphi 12.1

 

Will do a more complete comparison between the two installs.

 

 

[msohn 28]

13 minutes ago, Dave Craggs said:

Got these from the event log

 

 

 

The exception code is STATUS_FATAL_USER_CALLBACK_EXCEPTION, see https://superuser.com/a/1643581

 

At this stage, I'd try to run DependencyWalker on the bpl to check for missing dependencies.

Edited May 22 by msohn

[Dave Craggs 7]

Is that this? https://dependencywalker.com/

 

Looks quite old!

 

[Remy Lebeau 1403]

6 hours ago, Dave Craggs said:

Got these from the event log

 

0xEEDFADE is a Delphi exception. That's a good sign, it means it was thrown deliberately, not something unexpected like an Access Violation, etc.  The 2nd IDE instance that is debugging the 1st instance should be able to show you what the exception actually is.

6 hours ago, Dave Craggs said:

0xC000041D is STATUS_FATAL_USER_CALLBACK_EXCEPTION.  That is not a good sign.  Of course, it could also just be a side effect of the 1st error.

 

Do you have the same problem if you load the component package dynamically at runtime via LoadPackage()?  Or does the error happen strictly during install only?

 

[msohn 28]

5 hours ago, Dave Craggs said:

Is that this? https://dependencywalker.com/

 

Looks quite old!

 

Yes it does look old, but it still does the job for me. Did you give it a try?

[Davide Angeli 44]

14 hours ago, Dave Craggs said:

Looks quite old!

I don't know if could help but a rewrite of the old dependency walker is here: https://github.com/lucasg/Dependencies

Edited May 23 by Davide Angeli

[Dave Craggs 7]

The newer version of the dependency walker worked fine, no issues found.

 

I tried copying the bpl files from the working system and still had the same problem.

 

I wonder if there is a BPL conflict?

 

[Dave Craggs 7]

Yes - bpl conflict. These bpls are also stored in SYSWOW64. Conflicting with a previous version of Delphi. I need to  rename the BPL files so they are unique to Delphi12 I think.

 

[Anders Melander 1795]

2 hours ago, Davide Angeli said:

I don't know if could help but a rewrite of the old dependency walker is here: https://github.com/lucasg/Dependencies

Ugh. Rewritten in C# using WPF, It's ironic that they've named the new application "Dependencies"; The old one had 1 DLL. The new has 54 DLLs.

 

[msohn 28]

34 minutes ago, Dave Craggs said:

Yes - bpl conflict. These bpls are also stored in SYSWOW64. Conflicting with a previous version of Delphi. I need to  rename the BPL files so they are unique to Delphi12 I think.

 

You might want to consider using $LIBSUFFIX AUTO which is around since 10.4 IIRC. See https://docwiki.embarcadero.com/RADStudio/Athens/en/Description

[Dave Craggs 7]

Libsuffix auto is the way to go., Thanks

 

[Pat Foley 51]

Also the 290 version should be given a new guid unless using the '280' source is wanted. A new interface needs a new guid.