Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Exception : Access violation at address 05D90E45 in module 'isapi.dll'
#1
Hello,
when we have many users connected to our site, we constantly receive access violation exceptions and this in the following cause of the slowdowns in our system. First of all, from a first glance at the file of the error stack it seems not to be due to our error but there are exceptions due to another reason. For this reason I wanted to talk to you to find out if it can be my mistake or not.
I attach the stack-trace file of the error.
Thank you
Andrea


Attached Files
.txt   Exception@2020-01-07 09-13-21.594.txt (Size: 9.62 KB / Downloads: 21)
.txt   Exception@2020-01-07 09-13-22.172.txt (Size: 5.86 KB / Downloads: 7)
.txt   Exception@2020-01-07 09-13-22.625.txt (Size: 5.02 KB / Downloads: 6)
Reply
#2
I can say with 99% certainty it is your code. IW is used in many large deployments and is well tested.

You can take a simple demo like Guess and deploy it and see that even under load it wont crash.

From the traces it appears that in your events something is creating an invalid state or memory issues.
Reply
#3
(01-07-2020, 03:03 PM)kudzu Wrote: I can say with 99% certainty it is your code. IW is used in many large deployments and is well tested.

You can take a simple demo like Guess and deploy it and see that even under load it wont crash.

From the traces it appears that in your events something is creating an invalid state or memory issues.

Thank you for the response.
What do you think is the best way to isolate the error?

In debugging I can't reproduce the situation. How can I simulate the stress-text situation in debugging ?
P.S. the application is 32 bit on a windows server 2016 64 bit. The memory usage is 2gb not 4gb ? It is correct ? To use 4 gb i must enable a directive in dpr project. In your opinion could be better ?

Thank you
Reply
#4
Memory is probably not the issue and if it is, then you probably have a serious memory leak.

You can use web stress tools to stress your app.

I would suggest trying something like MadExcept to help with the crash logging.
Reply
#5
In all of the stack traces I see references to IWBS components. Besides that, at first, looks to me that somehow the form being executed has been released prematurely. Is that possible? How are you creating/destroying your forms?

Forget what I said above. The issue seems to be during the destruction of one of the forms, this is what happens: 
- IWContainers of the form are being destroyed and destroy all child controls
TIWBSCustomRegion.Destroy is called
TIWBSCustomControl.Destroy is called -> somewhere here down the line an AV happens

Seems to be related to the destruction of one descendant of TIWBSCustomControl
Reply
#6
I don't think memory is an issue here. Unless you have thousands of users connected, you shouldn't reach 2 gb easily.

Do you have other exception log files as these? Can you make them available (it can be G-drive or dropbox) and send me a link to my email (alexandre at atozed dot com)?
Reply
#7
All 3 stack traces belong to the same session and occurred in sequence. The last 2 are consequences of the first and I doubt they have anything useful. The first one shows that one of your forms was begin destroyed (BSVisualizzaCedForm, BSStampaCed1Form or BSStampaCed2Form ??). During the release of these forms something caused an AV. Anything unusual about the destruction of one of the forms?
Reply
#8
This may be unrelated but it is adviced that when you declare an object, you set its value to nil in onFormCreate

var
s: TBitmap;

onFormCreate
s:=nil;

This is useful in case you do not create the object by

s:= TBitmap.Create;

because when you free the object with

if assigned(s) then FreeAndNil(s);

you will get acces violation since "s" will not have "nil" value and so it will be undetected by "if assigned"
Reply
#9
(01-08-2020, 08:17 PM)Alexandre Machado Wrote: In all of the stack traces I see references to IWBS components. Besides that, at first, looks to me that somehow the form being executed has been released prematurely. Is that possible? How are you creating/destroying your forms?

Forget what I said above. The issue seems to be during the destruction of one of the forms, this is what happens: 
- IWContainers of the form are being destroyed and destroy all child controls
TIWBSCustomRegion.Destroy is called
TIWBSCustomControl.Destroy is called -> somewhere here down the line an AV happens

Seems to be related to the destruction of one descendant of TIWBSCustomControl
Hi Alexandre,
thanks for your answers.
After numerous stress tests on my app I came to the same conclusion that it may be a bug in the bootstrap library (TIWBSCustomControl). Can I help you? What should I do to solve the problem?

Andrea
Reply
#10
If you could share this form (even if it doesn't compile) it would be good, so I could try to understand what is the sequence of events.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)