Jump to content
Dave Craggs

Access violation installing a component

Recommended Posts

Posted (edited)

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

 

image.thumb.png.fcfb544ae92f687d26b15b0038eaa115.png 

 

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

 

image.png.ab896642fa756f80dc060ca4b2362821.png

 

How can you debug this sort of thing?

 

Dave Craggs

Edited by Dave Craggs

Share this post


Link to post

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. 

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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:

image.thumb.png.1d010d3e56be7bccbbd23a1222d8dc51.png

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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).

Share this post


Link to post

This is strange

 

Got these from the event log

 

image.png.7f83303e9eb8c1f9622294334da94a9f.png

 

image.thumb.png.852fbb218a599c79c1e27c84ccf45d0d.png

 

This is Delphi 12.1

 

Will do a more complete comparison between the two installs.

 

 

Share this post


Link to post
Posted (edited)
13 minutes ago, Dave Craggs said:

Got these from the event log

 

image.png.7f83303e9eb8c1f9622294334da94a9f.png

 

image.thumb.png.852fbb218a599c79c1e27c84ccf45d0d.png

 

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 by msohn

Share this post


Link to post
6 hours ago, Dave Craggs said:

Got these from the event log

 

image.png.7f83303e9eb8c1f9622294334da94a9f.png

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:

image.thumb.png.852fbb218a599c79c1e27c84ccf45d0d.png

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?

 

Share this post


Link to post
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?

  • Like 1

Share this post


Link to post

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?

 

Share this post


Link to post

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.

 

Share this post


Link to post
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.

 

image.thumb.png.9793832b511406026a1d115b94c17447.png

  • Haha 2

Share this post


Link to post
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

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×