TComboBox / TDBComboBox - Access Violation - read of address 00098053
Jason Loucks
I have a fun problem that I am trying to get to the bottom of:
1. After moving to Windows 2000, people randomly get errors like:
Access violation at address 00452BOC in module 'inbound_calls.exe'. Read of
address 00098053.
2. It always is a read of address 00098053, and the access violation
always occurs in the ScreenToClient method of TControl.
3. It doesn't happen every time, and will sometimes happen to one
TDBComboBox, but not the TDBComboBox right beside it.
4. It only happens when the mouse pointer floats over the "dropped down"
part of the T(DB)ComboBox.
5. Logging off and logging back in resolves the problem in most (>95%)
cases. Rebooting in the rest. Closing down and restarting the application
does NOT solve the problem ever that I can see.
6. We are using roaming profiles and are on a W2K only with AD. Also,
before our clients went to W2k I had no reports of this happening under NT4.
And, it happened under Delphi 5 code and Delphi 6 code. And using nt4 as
the compiler platform and W2K as the compiler platform. It has happened to
code built from two different machines.
I have opened a case with Borland, but as it is hard to reproduce, I am
hoping that someone else out there may have experienced something like this
and give me pointers or something.
--Jason
loucks@@aim..andrews...edu
Vinnie Murdico
You are not alone... unfortunately.
Check Google newsgroup search for "access violation 00098053" and you'll get
a few threads. One or two of my customers have seen it, too.
Unfortunately, I have not yet seen a definitive solution for this problem.
Others get the same AV at exactly the same "read of" address in
TControls.ScreenToClient as well.
Not being able to reproduce it here, I have not be able to troubleshoot it.
Several other developers also have tickets open with Borland. However, the
word I've heard is that unless is reproducible, Borland probably won't do
much with it. (I hope this isn't true.)
-- Vinnie Murdico
Mike Orriss (TeamB)
> However, the
> word I've heard is that unless is reproducible, Borland probably won't do
> much with it. (I hope this isn't true.)
>
Unless it is reproducible how can they?
Mike Orriss (TeamB and DevExpress)
Jason Loucks
the discussions there. I have a suspicion that parent for these little
buggers is not getting set right.
--Jason
"Vinnie Murdico" <vin...@softwarewithbrains.com> wrote in message
news:3c854bda_1@dnews...
Vinnie Murdico
I fully understand and agree that they can't *easily* correct a bug that
they can't reproduce. But when several developers all report the same
critical bug (this is definitely a show-stopper for some of our customers),
AND the developers continue to report additional information and insights in
an attempt to narrow down the source, I would expect Borland to at least
*look* at the source code for the routines in question and see if anything
"stands out" as a potential problem. Since they wrote the source code, they
are likely the best people to determine if something does not look right.
Some Delphi users have been reading the VCL source and attempting to suggest
different possible causes and solutions. Others (like myself) simply don't
feel comfortable making changes to the VCL because we may not understand
exactly what it is doing -- especially in this case where the code in
question in Controls.pas can get rather complex and relies on Win32 API
calls and other advanced functions. But, since presumably Borland would be
best suited to review and analyze this code because they wrote it --
therefore they *should* have the best understanding of what it needs to do
in this case, and it should be more apparent to the original developer
whether or not a problem *may* exist in a particular routine.
I've certainly had situations where a customer has reported a bug that I
could not reproduce based simply on the information provided. But as the
product's producer, I had a better idea where the problem *might* be coming
from and therefore I could at least narrow down the field to certain suspect
logic and review those functions to see if any of them might cause the
problem. In many cases, this was how I determine the cause of the problem
(even before I could reproduce it) -- by just reviewing and walking through
the code to see how I could make it happen if I wanted to.
When our customer first reported this issue, we didn't simply throw up our
hands and say "We can't reproduce it." We've been working with this
customer every week for the past few months to attempt to get closer to
narrowing down the cause. We've tried various patches on the VCL and been
in constant contact with the customer to monitor the results and gain as
much information as we could about the circumstances surrounding this issue.
I'd like to see Borland take the same "active interest" in this critical
error as we've take with our customers.
I'm simply saying that I hope Borland does not simply look at each bug
report as it comes in and file it under "Later" if it says "Not
Reproducible". That would be a shame because the severity and priority of
an issue are not necessarily factors of its reproducibility.
This issue seems to be coming up more and more by different developers. It
is a "critical" app-stopping error that appears in the EXE in the field (as
opposed to an IDE issue). It is a severe issue that at least warrants
review on Borland's behalf. I'd rather have a response that says "We can't
reproduce it, but we have some ideas as to what may cause it, so let's work
together and see if we can solve it for your customers..." than to hear
nothing at all. There has been more of this type of input from the
developers in the newsgroups researching this problem than from Borland
itself, and Borland presumably should be best equipped to say at least where
the problem *might* be coming from and to offer suggestions. As the producer
of Delphi, It has to be easier for them than it is for us to understand the
code involved in this issue. It's not reproducible for the developers in
this newsgroup either, but they've certainly had much more dialog and input
about it with each other than Borland has had with us.
-- Vinnie Murdico
David Clegg
> Please enlighten me on the google newsgroup search... I would like to
> join the discussions there. I have a suspicion that parent for these
> little buggers is not getting set right.
goto www.google.com , select Groups and search away. (oops, did I just use a
goto?) :-)
--
Cheers,
David Clegg
dclegg_at_ebetonline_dot_com.
Vinnie Murdico
in the first field to search on ALL terms (an AND condition). You can
limit it to Borland newsgroups if you want by entering "borland.public.*" in
the newsgroup field.
http://www.google.com/advanced_group_search?hl=en
-- Vinnie Murdico
Alexander Tarasul
On our test machine we were not able to repro AV after the fix.
We opened ticket with Borland and sending them our change for review.
We also will deploy it (limited) on the field to users and will see
if AV will go away.
I'll keep you posted about Borland reply and our field test.
Thanks
Alexander Tarasul
www.tarasul.com
Mike Orriss (TeamB)
> I fully understand and agree that they can't *easily* correct a bug that
> they can't reproduce. But when several developers all report the same
> critical bug (this is definitely a show-stopper for some of our customers),
> AND the developers continue to report additional information and insights in
> an attempt to narrow down the source, I would expect Borland to at least
> *look* at the source code for the routines in question and see if anything
> "stands out" as a potential problem. Since they wrote the source code, they
> are likely the best people to determine if something does not look right.
>
What makes you think they don't look at the source? Having said that, the only
way to be sure that the bug is fixed is being able to reproduce and then prove
that the changes work.
Vinnie Murdico
only
> way to be sure that the bug is fixed is being able to reproduce and then
prove
> that the changes work.
The problem is, we get no information from Borland to let us know they *are*
looking at it. The email response I got to my submission gave me a link to
a web page where I can view exactly what I originally submitted along with
my personal information. It tells me *nothing* about the status of the
issue I reported in terms of Borland's R&D efforts. It doesn't even tell me
it's assigned to anyone. (The response email also tells me I can add
additional information on that web page which does not seem possible on that
page. I must use email to add information.)
Additionally, none of the developers I have been communicating with
regarding this same issue have received any communication from Borland
regarding *their* submissions of the same problem.
I would simply like to see better communication on the part of Borland.
Please, Borland -- ask us questions about this issue. Tell us you need more
information. Send us some "temporary" patches to try at our customers'
sites... throw us a freakin' bone here <said in Dr. Evil voice>...
Why do they have to *definitively solve* the problem before talking to us at
all? Why not work interactively with us to solve this issue since we have
access to the people who *are* experiencing the error.
Right now we've got no idea what is being done (or not being done) about
this issue.
-- Vinnie Murdico
Steve Trefethen (Borland Delphi R&D)
FWIW, I've followed this entire thread. However, without a reproducible
case (as mentioned several times) there is little we can do. I've reviewed
the code and there isn't anything that jumps out at me. I've asked tech
support for more information but have yet to receive anything as I believe
they are still waiting on a customer callback for more information. I've
tested this on a number of machines and am unable to reproduce the problem
using a simple csDropDown TComboBox. Short of simply debugging this problem
I'm not sure what else I can offer. From what I've seen so far:
- The error appears to occur in the call to FindDragTarget from
.DoMouseIdle.
- It appears that the AV occurs due to a non nil invalid result coming back
from FindVCLWindow.
This is simply a guess since I can't reproduce it.
Are there any controls under the area where the dropdown appears?
If so, what are they?
What events (if any) are assigned on the TComboBox?
In the first post of this thread Jason states that it happens in D5 code as
well. This is troubling because it indicates to me that the problem has
likely been around awhile but is very obscure since we haven't really heard
much about it until recently.
Another approach is to try and determine what the machines that have this
problem have in common. Mouse drivers? Video drivers? etc.
Anyway, support here is not official and if you look at the time of this
post it really is 11:06pm PST on Monday night which is not part of my
regular working hours and now I'm headed to bed...
--
-Steve
Delphi/C++ Builder R&D
Borland Software Corporation
Please, no private email, unless specifically invited in this message, thank
you.
http://www.geocities.com/delphihelp
Have you tried searching http://groups.google.com first?
Vinnie Murdico
Thanks for the response. I feared that Borland's policy would be just
that -- not much effort could be allocated to resarch a non-reproducible
problem.
However, I am glad that you responded with the questions you asked. It's a
shame that you had to ask them during "off hours" on your own time. Does
this indicate that you are not allowed to allocate "official" work time to
this problem because it's not reproducible? That would be a real shame. I
wish we could tell our customers we were unable to work on non-reproducible
errors. I can see where it would really save the developers time not having
to expend effort researching something that may not yield quick results.
However, we have told our customers that we will continue to work on this
until we come to some type of resolution -- however long that takes -- and
we will do just that regardless of the cost.
In any event, I have addressed each of your questions below with as much
information as I can find from my customer converstaions regarding this
matter. Perhaps my collegues will also jump in and contribute more
information:
>> The error appears to occur in the call to FindDragTarget
from.DoMouseIdle.
>> It appears that the AV occurs due to a non nil invalid result coming back
from FindVCLWindow.
This definitely seems like the scenario we have all been experiencing. The
developers I've spoken with have all pointed to this type of problem
(invalid control pointer/handle) from one of these routines. Is it possible
to determine if the result is a valid object for the current application and
trap for the problem? Is that how the result is "invalid" -- that is
doesn't belong to the current application? I realize you can't reproduce
it, but if we could try some code of this sort, *we* could let you know if
it has worked since several of us have customers who experience the problem
somewhat regularly. Even without proof that the precise problem was
eradicated, if it went away and we didn't see it for several months (instead
of days or weeks), that would be better! Plus, the results may help us
deduce where the problem is, especially if we see a change in behavior with
some code changes in place.
>> Are there any controls under the area where the dropdown appears?
In our case, the controls under the combo box (when dropped) are two other
combo boxes. It primarily happens on one particular window (although the
rest of our app has less-used screens and not many combo boxes) so it could
be a matter of probability that it happens mostly on the one highly-used
window. There are a few reports of it happening on other windows in the
app. The other windows have various controls under the combo box in use
when the error occurs.
>> What events (if any) are assigned on the TComboBox?
In our case, there are no events coded whatsoever for the combobox controls
in question, nor for the controls "underneath" the combos.
>>In the first post of this thread Jason states that it happens in D5 code
as
>> well. This is troubling because it indicates to me that the problem has
>> likely been around awhile but is very obscure since we haven't really
heard
>> much about it until recently.
I can also confirm that - Our product was in D5 until a few weeks ago, and
we have not released the D6 version yet. All occurrences of the error
experienced by our customers were under D5 code. It definitely seems to be
more prevalent under NT4 and 2000 than under 95/98. In fact, I have no
reports of the problem from users running 95/98 (and we do have some users
on that platform). Is it perhaps surfacing more frequently now as more
users move to later builds of NT4 (SP5/6), or Win 2000 and XP? I would not
be surprised if there was something about Win NT4/2000/XP that exacerbates
the problem, simply because most of the developers I've spoken to have seen
the problem occur more frequently just recently. I think one mentioned that
it only started happening when they upgraded their customers to Win 2000.
>> Another approach is to try and determine what the machines that have this
>> problem have in common. Mouse drivers? Video drivers? etc.
One of the threads I was involved in under one of the Borland newsgroups
actually had started discussing this -- We had originally had some idea that
ATI video cards were involved, but I have since heard of other cards
(Matrox) that were installed on machines that had the error, so unless they
use similar chipsets/drivers, I don't think it's a video driver/hardware
problem. Our customer did have 3 ATI video cards (various models) on her
machines, but given that the problem occurred on a non-ATI system for
another developer, it would seem that is not the primary cause.
One issue that has also come up is the use of Norton Anti-Virus on the
systems. I know our customer has mentioned having NAV installed and running
on their systems, and I don't think we've tried disabling it yet. I don't
know from the other developers in this thread if any do *not* have NAV
installed on the machines in question. Perhaps some of the other developers
can jump in and let us know if this is another "red herring".
I also checked the mouse drivers with our customer that gets the problem
regularly. She said that they have the MS Intellipoint mouse installed on
one station. Since that mouse driver was related to an old TDBLookupCombo
bug we even swapped out the dblookup combos for regular combos, but the
problem persisted. She also had a station with a Logitech mouse that got
the error. Also, she mentioned that some mice had "scroll wheels" and some
were simple serial mice that did not, so the wheel does not seem to be a
factor in this problem, nor is it particular to PS/2 or serial mice in this
case.
With this customer they originally had the following specs common to the
machines where the error occurred:
WinNT 4.0 (Build 1381) with SP5, Visual SourceSafe, Norton AntiVirus and
SQL 7.0, MS Office/MS Outlook
The same customer recently changed her PC to a new one:
IBM 1.5Ghz, 128mbs RAM, Win2000 with the same software, but newer
versions installed now.
The error still occurs. I have Dr. Watson dump information if that is
helpful:
===========================
State Dump for Thread Id 0x1d0
eax=00098053 ebx=00098053 ecx=0012fef8 edx=0012fedc esi=0012ff14
edi=0012fef8
eip=00439858 esp=0012fedc ebp=00098053 iopl=0 nv up ei pl nz na pe
cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010203
function: <nosymbols>
00439847 c3 ret
00439848 53 push ebx
00439849 56 push esi
0043984a 57 push edi
0043984b 83c4f8 add esp,0xf8
0043984e 8bf9 mov edi,ecx
00439850 8bf2 mov esi,edx
00439852 8bd8 mov ebx,eax
00439854 8bd4 mov edx,esp
00439856 8bc3 mov eax,ebx
FAULT ->00439858 8b08 mov ecx,[eax]
ds:00098053=????????
0043985a ff513c call dword ptr [ecx+0x3c]
ds:00c0d4ca=????????
0043985d 8b06 mov eax,[esi]
ds:0012ff14=000002fc
0043985f 2b0424 sub eax,[esp]
ss:0012fedc=0001000c
00439862 8907 mov [edi],eax
ds:0012fef8=7ffde000
00439864 8b4604 mov eax,[esi+0x4]
ds:00c0d4e6=????????
00439867 2b442404 sub eax,[esp+0x4]
ss:00c0d4af=????????
0043986b 894704 mov [edi+0x4],eax
ds:00c0d4ca=????????
0043986e 59 pop ecx
0043986f 5a pop edx
00439870 5f pop edi
00439871 5e pop esi
=============================
I believe when I checked the current MAP file at the time this was reported,
this code was in TControls.ScreenToClient.
Steve, again I appreciate you taking the time to respond "off the books". I
wish someone could be assigned to this problem "on the books", but every
company has its policies and I understand (although it doesn't raise my
opinion of Borland's customer service in this case <g>)..
If there are any suggestions or possible code patches that you think we can
try to determine where this is happening, please let us know. Like I said,
I'd be willing to build our EXE with a patch for a "possible" solution and
have our customer try it out -- I know they won't mind trying out new
possible fixes.
The scary thing is that this bug alone could literally "kill" a retail
product. If the problem truly does occur more frequently on the newer OSs
such as Win 2K (which seems to be the case as it is occurring more
frequently these days for several developers), then customers downloading a
demo may experience the error and decide not to purchase because the product
seems unstable. If this happens in even a modest percent of the cases where
a potential customer would otherwise be willing to buy the product, it could
be disastrous.
Any additional help would be greatly appreciated.
Sincerely,
-- Vinnie Murdico
Vinnie Murdico
Have you read the thread below posted by Hallvard Vassbotn started on
2/28/02 and continued on 3/6/02 and 3/07/02?
It is titled "AV in TControl.ScreenToClient - possible workaround". In the
initial post and his own follow-ups, he posts some Delphi code to duplicate
the error by force, and then a possible patch to the VCL to handle it.
Could you look at that and see if it helps Borland to reconsider this issue
as reproducible, or at least if it helps to spark some thoughts about what
might be causing the problem and how it might be fixed?
Thanks,
-- Vinnie Murdico
Dusty Carnahan
platform from windows 98 to Windows 2000 Pro (about three months ago) ... we
have several programs written in D4 and all users have had this now infamous
AV 00098053 ...
I have many comments concerning how unhappy I am with Borland and tried
to discuss this with them but found myself on the short end of the stick ...
I could go on and on but this isn't the place for it ... but it should be
noted that Borland has been extremely less than helpfull with regards to
this issue ...
I also need to point out that not all problems are reproducable at a
whim ... if they were then most tech support offices, mechanics and
troubleshooters the world over would be out of business ...
Our troubleshooting has eliminated hardware as an issue ... in our
deployments we have a variety of video, NIC, memory, mice and etc ... each
station has had the AV error ... we spent two weeks determining this ...
even our laptops exhibit the AV ...
The issue as we see it is with how Win2k and NT Sp6 are now reporting
mouse movements and that the VCL at times intercepts the mouse message, even
when it shouldn't ... Win98 isn't as "efficient" as the NT platform;
sometimes ignorance is bliss ...
We run Win2k with Office XP and have had the problem a lot ... the AV
has even occured when a user has the program minimized and they are reading
email in Outlook; they move their mouse and the Delphi program generates the
AV ... we have run a bug sniffer and narrowed the problem code down to the
Controls.pas and FindControl ...
We program in D4 but to satisfy ourselves that the problem was not just
D4 we down loaded the D6 package, recompiled and still had the problem ...
if the probelm did not occur in D6 I would have happily spent the money and
upgraded our D4 C/S installations ... but this wasn't the case ...
We stripped workstations down to just the basic load of Win2k and Office
XP and still had the problem ... now the interesting thing we did next was
to run just Win2k (no Office products) and we did NOT have any errors ...
this got our attention ... it is very possible that the MS products like
Word, Excel or Outlook are sending bogus mouse messages; sounds like a MS
problem ... well, yes and no ... yes they can be sending bogus mouse
messages but other programs know not to listen; shouldn't our programs do
the same ? ... this is when we began looking deeper at the possible issue is
that Controls.pas isn't ignoring bogus mouse messages, that nil handles or
non-existent windows are trying to be passed within the VCL when they
shouldn't be ...
We have made a mod to the FindControl routine in hopes that any bogus
messages we catch and bit bucket them instead of allowing them to pass
through the code ... so far so good ... but since this is truely an
intermittent problem only time will tell ...
Thanks,
Dusty Carnahan
"Vinnie Murdico" <vin...@softwarewithbrains.com> wrote in message
news:3c8eaf7b$1_2@dnews...
Steve Trefethen (Borland Delphi R&D)
Thanks for contributing your information...
> We have made a mod to the FindControl routine in hopes that any bogus
> messages we catch and bit bucket them instead of allowing them to pass
> through the code ... so far so good ... but since this is truely an
> intermittent problem only time will tell ...
Can you please post the mods you made to FindControl?
Thanks
Vinnie Murdico
news:3c8ebb1d$1_2@dnews...
>we have several programs written in D4 and all users have had this now
>infamous AV 00098053 ...
Guess that makes *three* Delphi versions the problem has affected... :-(
>We run Win2k with Office XP and have had the problem a lot ... the AV
>has even occured when a user has the program minimized and they are reading
>email in Outlook; they move their mouse and the Delphi program generates
the
>AV ...
We also had this happen with one customer. They were in Outlook or Outlook
Express reading emails with our app *minimized* and our app generated an AV
while minimized. I'm assuming the two problems are related, but there are
definitely two distinct manifestations of this problem: One while dropping
down a combo list and moving the mouse over the list, and another while the
app is not even the active foreground app.
-- Vinnie
Nick Hodges (TeamB)
I don't have any help for your problem, but I do want to point out
that these forums are user-supported forums, and there is no guarantee
that Borland will notice or respond to anything here in these groups.
As it so happens, you have gotten a reply from Steve Trefethen, who
reads these newsgroups because he is a conscientious guy.
I don't say this to try to stop you from posting or seeking a solution
here, but merely to make sure you and everyone knows that this is
_not_ the place to expect a reply from Borland.
Nick Hodges
Lemanix Corporation
How to ask questions of techies --
http://www.tuxedo.org/~esr/faqs/smart-questions.html
Vinnie Murdico
these newsgroups, and I fully appreciate Steve's response here. I just
wanted to vent my contention that it seemed like he basically had to
approach this problem "on his own time" in a forum where officially Borland
is not really "doing support" as you have indicated.
I simply would have wished Borland would have let someone research this
problem on "Borland's time" since it seemed it was a pretty serious
issue.... yes, yes, yes -- even though it could not be reproduced and how
could anyone ever fix something that was not 100% reproducible? <g>
But nevertheless, Steve is to be commended for going above and beyond the
call to request more information and help us out with this problem, even
though it seems like he's going against company policy to do it (shame it
has to be that way). I am very appreciative of *Steve's* support (but not
necessarily *Borland's* support) of the developers who have been plagued by
this particular problem (which seems to have existed for 3 revs of Delphi).
Maybe if we all chip in and get Steve one of those plastic "nose and
glasses" disguises and move him to a cubicle in the far corner, we could get
him to work on this on Borland's time, instead of having to do it during his
own time.
Thanks again, Steve, for all your assistance. I realize your hands are
basically tied, but anything you can offer is genuinely appreciated by all
of us here.
Best Regards,
Vinnie Murdico
Nick Hodges (TeamB)
<vin...@softwarewithbrains.com> wrote:
>
>I simply would have wished Borland would have let someone research this
>problem on "Borland's time" since it seemed it was a pretty serious
>issue.... yes, yes, yes -- even though it could not be reproduced and how
>could anyone ever fix something that was not 100% reproducible? <g>
Well, Steve is "officially" researching it. He is on the R&D team, so
obviously Borland knows about it. If there is a bug here, he will
enter it into their bug tracking system.
>
>But nevertheless, Steve is to be commended for going above and beyond the
>call to request more information and help us out with this problem, even
>though it seems like he's going against company policy to do it (shame it
>has to be that way).
He's not in anyway going against any policy Borland has -- Borland has
no policy _against_ employees coming here, not at all. However, I
just wanted to make sure that Borland makes no guarantee that any
employee will read or respond here. In fact, though, many do, and
Steve is one of them.
Vinnie Murdico
> enter it into their bug tracking system.
Sure they know about it -- But I was initially under the impression that
they wouldn't spend much (if any) time on it if it was "not reproducible".
And Steve's initial response in this group: "... without a reproducible case
(as mentioned several times) there is little we can do..." echoed that
concern as a valid one.
> Borland has no policy _against_ employees coming here, not at all.
Actually, I wasn't implying that Borland had a policy against employees
coming here and helping. I was implying that Borland's "policy" was more
like Steve's aforementioned statement. My initial fear was that Borland
would not "sanction" one of their employees working on this case very long
without some type of reproducible case -- and that would be a big problem.
The severity of an issue is not necessarily a factor of its reproducibiity.
If Steve is indeed working on this problem "officially", then that's
great -- we all welcome that and appreciate his efforts on Borland's behalf.
I just wish Borland had some mechanism to let us in on that fact and to keep
us better informed of the status of reported issues. On the original email
auto-response I received from the online problem submission page at the
Borland support site, it had a link to a web page. Unfortunately, this web
page simply regurgitates the information exactly as I had entered it. There
was no clear way to view the status of the issue or to see if someone was
assigned to it. Hence, the frustration most of us here felt.
Without such a communication mechanism, Borland can hardly blame developers
for feeling as if their problem is being ignored -- at least until a Borland
employee "unofficially" posts a response in the newsgroups on his own time.
It seems that there should be a better, more formal mechanism for developers
to review the status of the issues they report and for Borland employees to
"officially" respond (since this newsgroup is not the "official" place for
dialog with Borland). Yes, of course... that would be "paid" support! <g>
But seriously -- every bug has a current status and *some* notes made by the
researching party that could be shared with the submitter, even if he hasn't
paid for the right to have an official conversation with Borland R&D or tech
support.
If there is such a mechanism for developers without paid support contracts
to review the status of issues they have submitted, then it ought to be more
clearly stated in the auto-response email sent to developers after a bug
submission. The web page that the email points to displays the case ID and
says I should use that number to "check the status" of the issue, but does
not provide a link to where I can do that.
Can anyone tell me the URL to use to view existing cases and their current
status?
Thanks,
-- Vinnie
Nick Hodges (TeamB)
<vin...@softwarewithbrains.com> wrote:
>Sure they know about it -- But I was initially under the impression that
>they wouldn't spend much (if any) time on it if it was "not reproducible".
Of course they won't. Chasing bugs around that can't be reproduced is
a large waste of time.
>And Steve's initial response in this group: "... without a reproducible case
>(as mentioned several times) there is little we can do..." echoed that
>concern as a valid one.
What do you suggest they do if the bug can't be reproduced?
> My initial fear was that Borland
>would not "sanction" one of their employees working on this case very long
>without some type of reproducible case -- and that would be a big problem.
No need to fear -- such is the case. I think this is a wise policy.
>I just wish Borland had some mechanism to let us in on that fact and to keep
>us better informed of the status of reported issues.
Very soon now(tm) Borland will make public "BugCentral", or whatever
they are going to name it, and you'll be able to report bugs, discuss
them with the community, and see when Borland fixes them.
Two articles, if you haven't seen them.
http://community.borland.com/article/0,1410,27815,00.html
http://community.borland.com/article/0,1410,28497,00.html
You can even help name it --
http://community.borland.com/cgi-bin/pulse/pulse_page.cgi?sid=171
>There
>was no clear way to view the status of the issue or to see if someone was
>assigned to it. Hence, the frustration most of us here felt.
I understand the frustration -- but if you reported it via the web
page, it is in Borland's bug tracking system. You can rest assured of
that.
Jordan Russell
> "Dusty Carnahan" <du...@nationalcorp.com> wrote in message
> news:3c8ebb1d$1_2@dnews...
> >we have several programs written in D4 and all users have had this now
> >infamous AV 00098053 ...
>
> Guess that makes *three* Delphi versions the problem has affected... :-(
Actually I think you can safely say *all* Delphi and C++Builder versions are
affected.
I have an app compiled in Delphi 2 and get the "address 00098053" AV
reports.
And just a few minutes I got the same AV while working in a Delphi
5-compiled app...
--
Jordan Russell
Jordan Russell
I think I'm close to getting a reproducable case for you.
But here is what I've found so far:
The bogus 00098053 result from FindControl happens when it is called with
Handle equal to the desktop window, i.e. the result of GetDesktopWindow().
Changing the code to the following seals up the problem nicely in my tests.
function FindControl(Handle: HWnd): TWinControl;
begin
Result := nil;
if (Handle <> 0) and (Handle <> GetDesktopWindow) then
begin
Result := Pointer(GetProp(Handle, MakeIntAtom(ControlAtom)));
end;
end;
My guess is that the desktop window uses an atom for its own internal use.
And for some reason (Win2k bug probably), this atom sometimes ends up having
the same number as the atom the VCL dynamically allocates (ControlAtom).
Now as for why the AV usually only happens when the mouse is moved over a
combo box's dropdown list, it's because the dropdown list window
("ComboLBox" class) is normally the only window that doesn't have a VCL
control (TWinControl) as a parent. When FindVCLWindow can't find a VCL
control, it ends up calling FindControl on the desktop window.
--
Jordan Russell
Jordan Russell
Windows 2000 at least), and have a better understanding of what causes it.
It is a conflict with the Microsoft Identity Manager (msident.dll), used by
MS Outlook Express and possibly other MS apps.
When you start Outlook Express, the Identity Manager creates a global atom
by the name of "IDENTITY_LOGIN". It then sets a property on the desktop
window (the window returned by GetDesktopWindow) using that atom as the
property identifier. The value of the property is - you guessed it -
00098053.
Now apparently, even after you close Outlook Express, that property is never
removed from the desktop window. And in some cases, when the VCL allocates
ControlAtom by calling GlobalAddAtom, it gets the same atom identifier as
the one the Identity Manager used for setting the "IDENTITY_LOGIN" property.
And when FindControl(GetDesktopWindow) is called when this happens, the
result of the FindControl will be Pointer($00098053). Thus the access
violation.
So how can the AV be reproduced consistently? Change these lines in
Control.pas from:
ControlAtom := GlobalAddAtom(
StrFmt(AtomText, 'ControlOfs%.8X%.8X', [HInstance,
GetCurrentThreadID]));
to:
ControlAtom := GlobalAddAtom('IDENTITY_LOGIN');
Then start Outlook Express, open up Delphi, and run a project that makes use
of the modified Controls.pas. Then move the mouse over a combo box's
dropdown list, and you should consistently receive the "read of address
00098053" access violation.
So now the mystery is how two separately allocated atoms end up getting the
same identifier. One theory I have is that the MS Identity Manager uses code
similar to this:
var
Atom: TAtom;
begin
Atom := GlobalAddAtom('IDENTITY_LOGIN');
SetProp(GetDesktopWindow, Atom, $00098053);
GlobalDeleteAtom(Atom);
end;
There the atom is allocated, the property is set, but then the atom
identifier is freed, making it available for use by other applications. And
occasionally, the VCL will get that freed atom identifier when it calls
GlobalAddAtom itself.
How can the problem be worked around? One easy solution which I proposed in
my last post is changing FindControl to this:
function FindControl(Handle: HWnd): TWinControl;
begin
Result := nil;
if (Handle <> 0) and (Handle <> GetDesktopWindow) then
begin
Result := Pointer(GetProp(Handle, MakeIntAtom(ControlAtom)));
end;
end;
There, it never tries to call GetProp if Handle is equal to
GetDesktopWindow.
Another solution - which I think may be superior - is to check the process
ID of Handle before calling GetProp on it:
function FindControl(Handle: HWnd): TWinControl;
var
PID: DWORD;
begin
Result := nil;
if Handle <> 0 then
begin
if (GetWindowThreadProcessId(Handle, @PID) <> 0) and
(PID = GetCurrentProcessId) then
Result := Pointer(GetProp(Handle, MakeIntAtom(ControlAtom)))
end;
end;
This will not only protect against "bad properties" on the desktop window,
but also bad properties on other processes' windows.
Anyway, there you have it. Hope this information helps.
--
Jordan Russell
Steve Trefethen (Borland)
Thanks for posting more information. I've been discussing with a few
other engineers ways to bullet proof this code and one idea is to use the
GetWindowThreadProcessID to check the window handle passed to the
FindControl call to ensure that the handle is within the calling process.
Although based on Hallvards thread from 2/28 (AV in
TControl.ScreenToClient - possible workaround) this may not actually
completely solve the problem.
Here is the idea for using GetWindowThreadProcessID, notice that
ApplicationProcessID would need to be initialized elsewhere prior to this
code executing. FYI, I have not thoroughly tested the following code.
function FindControl(Handle: HWnd): TWinControl;
var
PID: Cardinal;
begin
Result := nil;
if (Handle <> 0) then
begin
GetWindowThreadProcessId(Handle, PID);
if PID = ApplicationProcessID then
if GlobalFindAtom(PChar(ControlAtomString)) = ControlAtom then
Result := Pointer(GetProp(Handle, MakeIntAtom(ControlAtom)))
else
Result := ObjectFromHWnd(Handle);
end;
end;
> Now as for why the AV usually only happens when the mouse is moved over a
> combo box's dropdown list, it's because the dropdown list window
> ("ComboLBox" class) is normally the only window that doesn't have a VCL
> control (TWinControl) as a parent. When FindVCLWindow can't find a VCL
> control, it ends up calling FindControl on the desktop window.
Agreed, this is the first thing that I was curious about given that I had
reorganized the combobox classes in D6 to allow us to implement
TCustomComboBoxEx as a descendant of TCustomCombo. One thing that you
notice immediate working with controls that have popup windows like this is
that they introduce all sorts of headaches. :)
> My guess is that the desktop window uses an atom for its own internal use.
> And for some reason (Win2k bug probably), this atom sometimes ends up
having
> the same number as the atom the VCL dynamically allocates (ControlAtom).
Again, I agree. Of course, if we can get a reproducible case then we could
forward it on to Microsoft in hopes that they actually fix the problem on
their side. At this point it's looking like the best we can do is to try
and hack around it.
--
-Steve
Delphi/C++ Builder R&D
Borland Software Corporation
Don't miss the 13th Annual Borland® Conference, May 18-22 in Anaheim,
California
http://www.borland.com/conf2002
Jordan Russell
message news:3c90ed7b_1@dnews...
> Hi Jordan,
> Thanks for posting more information.
Ah, we posted a couple of minutes apart. Please also see the further
information that I posted a few minutes ago.
> I've been discussing with a few
> other engineers ways to bullet proof this code and one idea is to use the
> GetWindowThreadProcessID to check the window handle passed to the
> FindControl call to ensure that the handle is within the calling process.
> Although based on Hallvards thread from 2/28 (AV in
> TControl.ScreenToClient - possible workaround) this may not actually
> completely solve the problem.
I believe it should.
> Here is the idea for using GetWindowThreadProcessID, notice that
> ApplicationProcessID would need to be initialized elsewhere prior to this
> code executing.
FYI, GetCurrentProcessId is an extremely lightweight call; it only consists
of two MOV instructions (on Windows 2000 at least). So I think you could get
away with calling GetCurrentProcessId every time...
> function FindControl(Handle: HWnd): TWinControl;
> var
> PID: Cardinal;
> begin
> Result := nil;
> if (Handle <> 0) then
> begin
> GetWindowThreadProcessId(Handle, PID);
Note: You aren't checking the result of GetWindowThreadProcessId here, or in
ObjectFromHWnd for that matter. You really should check if it returned a
non-zero value (i.e. succeeded) before trying to compare PID. (When
GetWindowThreadProcessId returns zero, it does NOT also set lpdwProcessId^
to zero.)
--
Jordan Russell
Jordan Russell
news:3c90ee0b$1_1@dnews...
> function FindControl(Handle: HWnd): TWinControl;
> begin
> Result := nil;
> if (Handle <> 0) and (Handle <> GetDesktopWindow) then
> begin
> Result := Pointer(GetProp(Handle, MakeIntAtom(ControlAtom)));
> end;
> end;
I should point out that I was working in Delphi 5 when I was modifying
Controls.pas. In Delphi 6, I see that there is also an ObjectFromHWnd()
call. That should be left in, of course.
--
Jordan Russell
Jordan Russell
little program which I used while debugging this issue that lists all global
atoms and displays the atoms owned by the desktop window.
--
Jordan Russell
Vinnie Murdico
> a large waste of time.
>
Ask other developers who are complaining about the problem for more
information, as finally has happened here (albeit after much begging, as per
my post on 3/11 pleading with Borland to open a dialog with us). Even
without duplication, a problem can be researched by reviewing the symptoms
and the code involved.
It would appear that the developers in this thread (and related threads),
namely Jordan Russel, Dusty Carnahan and Hallvard Vassbotn were able to come
very close (if not right on the mark) to locating and creating possible
solutions for this bug WITHOUT actually being able to definitively reproduce
it. I would imagine they used program MAP files to locate the error, looked
at the VCL code and thought "...what would cause this line to react this
way?...." Then they manually traced back through the VCL code to see how it
executed and came up with some *possible* causes and solutions.
Now yes, they can't *prove* those solutions will work because they can't
reproduce it at will (or actually, it looks like maybe Jordan has done
this). But they did the next logical thing -- they built the code with
their "test" patch in place and let the customer who *does* have the problem
try the code for a while. If the customer is getting the problem once a
day, and with the patch it doesn't appear for over a week, then you can at
least make an assumption that your on to something and continue from there.
I agree it's not the "formal", technical way to prove or disprove a bug
correction, but it's an ambiguous world full of grey tones. Some times you
just have to do whatever you *can* do -- the next best thing that *is*
possible -- even if it's not the complete solution. We have to at least
*try*. I can't simply throw up my hands when a customer reports this fatal
error and say, "Well sorry, it's not reproducible so we won't be able to
address it."
But my original point was that I wanted Borland to be a part of that
discussion and suggestion phase since they knew the code best and could
suggest the safest and most likely solution to the problem even if they
couldn't reproduce it. I am very happy that Steve has become a part of that
dialog and we appear to getting closer to a solution.
Without this thread becoming this "feverish", I'm not sure things would have
moved this quickly.
Please understand, I don't want my tone to be misinterpreted. I (and all of
us here I'm sure) truly do appreciate Steve's help on this matter. Not to
mention Jordan Russel, Dusty Carnahan and Hallvard Vassbotn who have all
done an outstanding job of narrowing down this app-killing bug. They should
all be commended for their efforts.
I think it was the lack of a formal communication/status mechanism with
Borland that exacerbated my angst in this case and caused me to "push" for
Borland's "public" aknowledgement of the issue in this case. At least now I
can tell my customer(s) that we truly are getting closer to a solution. And
with the suggestions made here, at least I can offer a possible code
solution for them to try in the meantime, until we are sure that the problem
has been eradicated.
Vinnie Murdico
YOU RULE!!!
I am going to make these proposed changes immediately so our customer can
try this new version.
I hope you get a free copy of D6, D7 (or something) for this ;-)
BTW -- excellent installer. Inno Setup rocks. We bailed on MSI after
several problems arose and moved to Inno and haven't looked back since.
-- Vinnie
Nick Hodges (TeamB)
I don't have any doubt that the R&D guys do what you've described
every day. However, I am also sure that given two bugs, one that is
reproducible, and one that is nebulous and may or may not even exist,
Borland should and will fix the reproducible one. That was my only
point.
Kudos to all of you here who have tracked this down.
Vinnie Murdico
Indeed!!! I can't thank everyone involved here enough.
-- Vinnie
Steve Trefethen (Borland)
>
> > Here is the idea for using GetWindowThreadProcessID, notice that
> > ApplicationProcessID would need to be initialized elsewhere prior to
this
> > code executing.
>
> FYI, GetCurrentProcessId is an extremely lightweight call; it only
consists
> of two MOV instructions (on Windows 2000 at least). So I think you could
get
> away with calling GetCurrentProcessId every time...
The GetCurrentProcessID API name escaped me at the time I posted. :)
> Note: You aren't checking the result of GetWindowThreadProcessId here, or
in
> ObjectFromHWnd for that matter. You really should check if it returned a
> non-zero value (i.e. succeeded) before trying to compare PID. (When
> GetWindowThreadProcessId returns zero, it does NOT also set lpdwProcessId^
> to zero.)
Yes, you're right, my code was more pseudo code posted before I had to run
to a meeting.
The important part now is the ensure that this actually fixes the problem
that people are seeing so at this point I would really like to hear feedback
from Jason, Vinnie, Hallvard and Dusty.
Jordan Russell
> When you start Outlook Express, the Identity Manager creates a global atom
> by the name of "IDENTITY_LOGIN". It then sets a property on the desktop
> window (the window returned by GetDesktopWindow) using that atom as the
> property identifier. The value of the property is - you guessed it -
> 00098053.
Small correction here: msident.dll actually doesn't explicitly create an
atom, it calls SetProp with a string constant. SetProp creates the atom
internally.
Here is the actual code from msident.dll:
71a03d0e 6853800900 push 0x98053
71a03d13 688415a071 push 0x71a01584 // "IDENTITY_LOGIN"
71a03d18 ffd3 call ebx {USER32!GetDesktopWindow (77e14c3e)}
71a03d1a 50 push eax
71a03d1b ffd6 call esi {USER32!SetPropA (77e1905b)}
Interestingly, 0x98053 is a constant. I wonder what it means...
--
Jordan Russell
Dusty Carnahan
The code patch that was written for the FindControl routine has been
working here without issue since it has been put in place ... I didn't post
it as this is a public forum and the code would be a modification of
Borlands original code; I get uneasy with copywrite and UCITA issues ... if
you would like please feel free to contact me directly and we can discuss
the code ...
Nice to see all the support and work ...
Thanks,
Dusty Carnahan
du...@nationalcorp.com
"Steve Trefethen (Borland Delphi R&D)" <stref...@nonborlandjunk.com> wrote
in message news:3c8f00ec$1_2@dnews...
Vinnie Murdico
I have incorporated the FindControl code that Jordan posted (his second
version -- the "more superior" patch <g>) and I have notified our customer
who was seeing the problem most frequently; probably on the order of several
occurrences a week. Hopefully she will be up for trying it. I think she
will -- she's been *extremely* cooperative and helpful in our diagnosis ever
since the problem became visible.
At this point, it will be a waiting game for us. It sounds like Dusty has
had good luck with his patch over a longer period of time (one or two
weeks?), which I think it pretty close to Jordan's code in terms of how it
fixes the FindControl function.
BTW -- our build is being done with Delphi 6 with the latest Delphi SP2
installed. I made the changes Jordan mentioned, also leaving in the extra
line of "ELSE" code that was not in his sample (the difference between the
D5 and D6 version).
Thanks again,
I'll keep you all posted as to what happens -- or hopefully, what *doesn't*
happen!
-- Vinnie
Hallvard Vassbotn
> The important part now is the ensure that this actually fixes the problem
> that people are seeing so at this point I would really like to hear
feedback
> from Jason, Vinnie, Hallvard and Dusty.
I missed this thread for a long time. Why didn't you guys just follow-up
on my original thread :-P?
Anyway, it seems like Jordan's fix solves this specific issue working
around a buggy code snippet in some Microsoft product (not the
first time is it?).
The problem with that is that it checks for a specific window
handle (the desktop window). IMO, it should be solved in a
more generic manner, as any other ill-behaved program will be
able to crash /all/ GUI Delphi applications running on the
machine.
The underlying problem is that any application can
SetProp a window handle of /any/ other application.
Ideally, Delphi should drop using SetProp/GetProp
altogether - instead using a private hash table of some
sort , mapping handle integers into object instance
pointers.
If you insist on continue useing SetProp/GetProp,
you have to check the value returned by GetProp to see
if it actually refers to a valid Delphi object:
function ValidateObj(Obj: TObject): Pointer;
type
PPVmt = ^PVmt;
PVmt = ^TVmt;
TVmt = record
SelfPtr : TClass;
Other : array[0..17] of pointer;
end;
var
Vmt: PVmt;
begin
Result := Obj;
if Assigned(Result) then
try
Vmt := PVmt(Obj.ClassType);
Dec(Vmt);
if Obj.ClassType <> Vmt.SelfPtr then
Result := nil;
except
Result := nil;
end;
end;
function FindControl(Handle: HWnd): TWinControl;
var
OwningProcess: DWORD;
begin
Result := nil;
if (Handle <> 0) then
begin
GetWindowThreadProcessID(Handle, OwningProcess);
if OwningProcess = GetCurrentProcessID then
begin
if GlobalFindAtom(PChar(ControlAtomString)) = ControlAtom then
Result := ValidateObj(TObject(GetProp(Handle,
MakeIntAtom(ControlAtom))))
else
Result := Pointer(SendMessage(Handle, RM_GetObjectInstance, 0, 0))
end;
end;
end;
Jordan Russell
news:3c9213bd_1@dnews...
> Anyway, it seems like Jordan's fix solves this specific issue working
> around a buggy code snippet in some Microsoft product (not the
> first time is it?).
>
> The problem with that is that it checks for a specific window
> handle (the desktop window).
That was my first fix. The second one checks the process ID. :)
> Ideally, Delphi should drop using SetProp/GetProp
> altogether - instead using a private hash table of some
> sort , mapping handle integers into object instance
> pointers.
That's a nice idea.
> If you insist on continue useing SetProp/GetProp,
> you have to check the value returned by GetProp to see
> if it actually refers to a valid Delphi object:
I assume you want to protect against other malicious processes corrupting
the window properties (?). While your code does ensure that the property
refers to a valid Delphi object, and prevent an access violation, it won't
stop the application from being rendered useless. If FindControl returns nil
on a VCL window, the window won't paint itself properly, it won't respond to
clicks, etc. IMO this might actually be a bad thing because it would mask
the problem, whereas an AV + crash would immediately raise a red flag.
--
Jordan Russell
Hallvard Vassbotn
> > If you insist on continue useing SetProp/GetProp,
> > you have to check the value returned by GetProp to see
> > if it actually refers to a valid Delphi object:
>
> I assume you want to protect against other malicious processes corrupting
> the window properties (?).
Yes, or just protect against other applications' buggy code.
> IMO this might actually be a bad thing because it would mask
> the problem, whereas an AV + crash would immediately raise a red flag.
As I said, SetProp/GetProp are unsafe. Putting pointer
values in with SetProp and reading them with GetProp
and dereferencing them is a bad idea, as any (admittedly
buggy or malicious) application may have overwritten
the property in the mean time.
Much better to just reuse the Handle -> Control mapping
setup by MakeObjectInstance by sending it a message like
in ObjectFromHWnd. The additional overhead is minimal.
Alternatively, use a fast structure like a hash table to store
the handle -> pointer mappings.
A third option is to have MakeObjectInstance store the
TWinControl address at a negative offset from the thunk
it currently creates. It should also store a magic cookie.
Then FindControl could (after checking the window
belongs to the current process) call GetWindowLong for
GWL_WndProc, check if the cookie is still there and
then read the control pointer. A little hacky, but safer
than GetProp.
SetProp and GetProp should be made obsolete, IMO.
Jordan Russell
the
> same identifier.
After pondering over this some more, I've figured out exactly how that
happens.
As stated previously, the Microsoft Identity Manager used by Outlook Express
sets a global property on the desktop window by the name of
"IDENTITY_LOGIN". It never deletes this property when you close Outlook
Express.
However, when you log off of Windows, the "global atom table is trashed",
i.e. cleared, as stated in the comments above the FindControl function in
D6's controls.pas. But, when you log off, no properties are cleared from the
desktop window.
So what happens is, the global atom associated with the "IDENTITY_LOGIN"
string gets deleted, but the property still remains on the desktop window
using this now-deleted atom.
When a new user logs onto the system, and runs a program that calls
GlobalAddAtom, that program will sometimes get the same atom ID.
This can be be demonstrated by running the DisplayAtoms program I posted
earlier in the attachments group. If you run Outlook Express, then run
DisplayAtoms, you'll get this output in the list of desktop window
properties:
'IDENTITY_LOGIN' = 00098053
OK, so far so good. Now log off and back on, and immediately run
DisplayAtoms again. You'll see that the name of the property changed:
'Delphi00000320' = 00098053
Oops - As seen above, the DisplayAtoms program has grabbed the same atom ID
that was formerly used for IDENTITY_LOGIN.
Now start Outlook Express again, and run DisplayAtoms again:
'Delphi00000320' = 00098053
'IDENTITY_LOGIN' = 00098053
Now there are two properties with the same 00098053 value.
--
Jordan Russell
Alexander Tarasul
That's a great find.
I've had similar patch, but now you've got confirmation of the REASON!!!.
The only addition is a need to patch one more function in Controls.pas
function IsDelphiHandle(Handle: HWND): Boolean;
which also using GetProp.
Vinnie Murdico
It's comforting to see the "true, behind-the-scenes" cause of the problem so
we can rest more surely knowing how it occurs and how to kill it. I (we
all) really appreciate you taking the time to hunt down this beast's
origins.
-- Vinnie
Steve Trefethen (Borland Delphi R&D)
"Hallvard Vassbotn" <hallvard...@c2i.net> wrote in message
news:3c9213bd_1@dnews...
>
> The underlying problem is that any application can
> SetProp a window handle of /any/ other application.
>
> Ideally, Delphi should drop using SetProp/GetProp
> altogether - instead using a private hash table of some
> sort , mapping handle integers into object instance
> pointers.
Yes, I agree and this is what I've been exploring. CLX uses this sort of
strategy but it can be problematic as well.
--
-Steve
Delphi/C++ Builder R&D
Borland Software Corporation