Board index » delphi » Access Violation in vcl70.bpl

Access Violation in vcl70.bpl

I am using D7.01, ADO and MS SQL Server 7, 2000 and 2005.

My app consists of a main executable with 60+ bpls (2000+ forms). Some are
loaded at startup, but most are loaded on demand using LoadLibrary.

I am trying to track down a specific access violation in vcl70.bpl.  I
created an error reporter years ago that sends me errors.  The specific
access violation has happened thousands of times with different offsets.  Of
course it doesn't happen all the time or in the same place and it cannot be
reproduced locally.

The error is "Access violation at address 00DDDA41 in module 'vcl70.bpl'.
Read of address ########".  The error points to different lines in
TCustomAction.Create which may be a red herring.

It is more likely to occur in a terminal server or Citrix implementation.

I haven't had much luck tracking these down.

Any ideas or comments on better ways to track down access violations?

 

Re:Access Violation in vcl70.bpl


Quote
Isaac Alexander wrote:
> I am using D7.01, ADO and MS SQL Server 7, 2000 and 2005.

> My app consists of a main executable with 60+ bpls (2000+ forms).
> Some are loaded at startup, but most are loaded on demand using
> LoadLibrary.

> I am trying to track down a specific access violation in vcl70.bpl.
> I created an error reporter years ago that sends me errors.  The
> specific access violation has happened thousands of times with
> different offsets.  Of course it doesn't happen all the time or in
> the same place and it cannot be reproduced locally.

> The error is "Access violation at address 00DDDA41 in module
> 'vcl70.bpl'. Read of address ########".  The error points to
> different lines in TCustomAction.Create which may be a red herring.

> It is more likely to occur in a terminal server or Citrix
> implementation.

> I haven't had much luck tracking these down.

> Any ideas or comments on better ways to track down access violations?

Did you try using something like madExcept, which can give you a stack
trace of "how"/when/where the exception happened?
www.madshi.net

00DDDA41 in module 'vcl70.bpl' is this always at the same location?

--
Pieter

Re:Access Violation in vcl70.bpl


Quote

> Did you try using something like madExcept, which can give you a stack
> trace of "how"/when/where the exception happened?
> www.madshi.net

I have never heard of these guys. I will check them out. Thanks.

Quote
> 00DDDA41 in module 'vcl70.bpl' is this always at the same location?

No, but 00DDDA41 is the most frequent error (50% of all errors) with 85% of
the 00DDDA41 errors reading from the same address "Access violation at
address 00DDDA41 in module 'vcl70.bpl'. Read of address 0000000C"

Re:Access Violation in vcl70.bpl


Quote
Isaac Alexander wrote:
> > Did you try using something like madExcept, which can give you a
> > stack trace of "how"/when/where the exception happened?
> > www.madshi.net

> I have never heard of these guys. I will check them out. Thanks.

It's actually just *one* guy AFAIK <g>

Quote
> > 00DDDA41 in module 'vcl70.bpl' is this always at the same location?

> No, but 00DDDA41 is the most frequent error (50% of all errors) with
> 85% of the 00DDDA41 errors reading from the same address "Access
> violation at address 00DDDA41 in module 'vcl70.bpl'. Read of address
> 0000000C"

Can the users reproduce it in one way or another?

Is it doable to run it without packages? In combination with a map file
you might get closer to where the error occurs.

Read of address 0000000C usually means reading from an object which is
already nilled. For instance:

var
  AComponent: TComponent;
begin
  AComponent := nil;
  Label1.Caption := IntToStr(AComponent.Tag);

will give a similar AV, accessing the Capacity property of a nilled
TList will also give a similar AV.

Now if there would only be a way to translate the code address to an
offset inside vcl70.bpl afterwards. Using TDump you can get the
contents of it. But even then you'll probably still be missing a stack
trace.

In your first post you're talking about TCustomAction.Create, where did
you get that information from?

Hmmm, AVs are easier to find with tools like madExcept.

Oh one more thing, in case you haven't tried it yet, it sometimes helps
to "reproduce" AVs by using FastMM4 in FullDebugMode.

http://sourceforge.net/projects/fastmm/

--
Pieter

Re:Access Violation in vcl70.bpl


Quote
> It's actually just *one* guy AFAIK <g>

Cool.

Quote

> Can the users reproduce it in one way or another?

The error doesn't happen every time and it can't be reproduced on demand.

Quote
> Is it doable to run it without packages? In combination with a map file
> you might get closer to where the error occurs.

This would be fairly involved.  It would give us a single 75MB executable.
I can look into it.

Quote
> Read of address 0000000C usually means reading from an object which is
> already nilled. For instance:

Interesting.  That's most likely the cause, but it does happen in several
different places.  We use a lot of TStringList and TList classes for in
memory record listings.

Quote

> Now if there would only be a way to translate the code address to an
> offset inside vcl70.bpl afterwards. Using TDump you can get the
> contents of it. But even then you'll probably still be missing a stack
> trace.

Yes.  That stack trace is the main reason I'm looking into madExcept

Quote

> In your first post you're talking about TCustomAction.Create, where did
> you get that information from?

When I entered the AV number into the Search | Find Error menu option, it
jumped to the hex view inside that method.

Quote

> Hmmm, AVs are easier to find with tools like madExcept.

I'm hoping so.

Quote
> Oh one more thing, in case you haven't tried it yet, it sometimes helps
> to "reproduce" AVs by using FastMM4 in FullDebugMode.

> http://sourceforge.net/projects/fastmm/

Thanks. I'll take a look.

Re:Access Violation in vcl70.bpl


"Isaac Alexander" <isaacNOS...@goNOSPAMprocura.com> wrote

Quote
> ... I'll take a look.

Isaac,  
If you find anything interesting, please let us know.
Rgds, JohnH

Other Threads