Chris,
> Bill: You may recall we were looking at switching back to some older code
> (commented out) in STBOutFiler<<writeInstanceVariables as a way to prevent
> STB corruption on some rare problem machines. Did you ever get this
change
> in a "problem" production environment?
Yes, within hours of your having suggested it. For whatever reason, the
problem had become so bad that it was interfering with normal operation.
> Did it eliminate the occasional STB
> corruptions?
With the understanding that it's sorta like answering the question "have
there been any more holes in that self-sealing fuel tank?", the answer
appears to be yes.
> Blair: I did not see the change in STBOutFiler<<writeInstanceVariables in
> the patch 2 beta. Depending upon Bill's response I wonder if it might be
> worth including in the patch. I know we were never able to completely
> understand this problem, or why this seemly unrelated code change fixed it
> for me. However I have tested it and with the code change I have never
been
> able to produce an STB corruption in D4 or D5 images or exes, while at the
> same time I can easily produce STB corruptions on my problem machine with
> the existing code in both images and exes.
I would strongly urge reversing the status of the two lines: comment out the
current code and return the old code to use.
> I have retired my problem
> machine from development, but since I am using STB as a persistence
> mechanism I am concerned that one of my end users may one day have a
similar
> "problem" machine. Bill's experience leads me to believe it is not only a
> Windows NT fluke.
It is DEFINITELY not confined to NT. NT provides an opportunity to debug it
more easily by making the problem more obvious, but it's merely a matter of
probability.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]
Locked
