| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 146.1 | | JAMIN::WASSER | John A. Wasser | Wed Mar 05 1997 10:40 | 22 |
| > Why does PWIOCB32.DLL break Reflection ?
(From one of the two QARs on this problem:)
Our investigation has so far shown that Reflection 4 is submitting an
I/O Control Block (IOCB) request with a null IOCB pointer. We think it
is trying to determine if the Local Area Terminal (LAT) transport is
installed but uses the wrong function code. This is filtering down to
the IOCB handler (DECIOCB) as a request with an invalid IOCB address.
Since DECIOCB is a kernel-mode driver, using this invalid address causes
a "Blue Screen" crash.
We are working with Walker Richer and Quinn (WRQ)to determine the cause
of the problem and to implement a full solution. The best we can do until
then is to prevent the blue-screen crash by having DECIOCB detect the null
IOCB pointer and treat the call as if it were an install check. This
interim fix will be in the released version of DECIOCB.SYS.
Unfortunately the interim fix currently results in a GPF crash in
Reflection 4. You should keep in mind that a full solution may require
changes in Reflection and possibly additional changes in one or more
PATHWORKS 32 components.
|
| 146.2 | | COPHK::copvm5.dmo.dec.com::cop01::jesper | | Wed Mar 05 1997 10:51 | 6 |
|
Thanks for the excelent and detailed explanation.
Regards
Jesper
|
| 146.3 | interim fix??? | VMSNET::DMCFARLAND | still TurboMom[tm]... | Fri May 23 1997 15:57 | 25 |
| O.K. I am gonna beat this dead horse again. I have been reading
the responses here and in note 308.
A new customer is running Reflection 5.2 over TELNET, not LAT.
Installing PW32 breaks this until he removes the PWIOCB. Of course,
PW32 does not work after PWIOCB is removed.
My question for John...I am a bit confused by:
> The best we can do until then is to prevent the blue-screen crash by
> having DECIOCB detect the null IOCB pointer and treat the call as if it
> were an install check. This interim fix will be in the released
> version of DECIOCB.SYS.
>
> Unfortunately, the interim fix currently results in a GPF crash in
> Reflection 4. Keep in mind that a full solution may require changes in
> the Reflection product and possibly additional changes in one or more
> PATHWORKS 32 components
If the interim fix still causes Reflection to crash, what kind of fix
is it? Is this "interim fix" part of PW32 v7.0a patch? Or is there
something better?
Diane
|
| 146.4 | | SPELNK::curless | | Fri May 23 1997 16:19 | 7 |
|
The fix is... it doesn't KILL THE MACHINE, just the application that
violates the spec.
Just like any API will.
Jeff
|
| 146.5 | more questions...thanx for your patience | VMSNET::DMCFARLAND | still TurboMom[tm]... | Fri May 23 1997 17:19 | 22 |
| Jeff,
Thank you. Now, if I've got this straight, the interim fix still
does not make the application (Reflection, in this case) work
correctly with PW32. Correct?
Re: the "spec being violated"...does this refer to what John said
about "Reflection submitting an I/O Control Block (IOCB) request
with a null IOCB pointer... This is filtering down to
the IOCB handler (DECIOCB) as a request with an invalid IOCB address.
Since DECIOCB is a kernel-mode driver, using this invalid address
causes a Blue Screen crash."???
Are we working on something ourselves to make this work? Or is the
onus still on WRQ?
(Just curious about the "interim fix"--is this part of the SSB 7.0
or included in 7.0a?)
Diane
(I know...I ask a lot of questions for someone from Alpharetta...)
|
| 146.6 | | SPELNK::curless | | Fri May 23 1997 17:38 | 17 |
|
The problem is still with WRQ.. they need to submit the IOCB call correctly,
or... their application will still crash. This is much like calling ANY
API incorrectly, the result can and usually will result in the application
crashing.
There is nothing we can do about the IOCB call (other than what we did, which
as to increase the validation on the parameters), except refuse those
calls that pass in what appears to be invalid parameters (a NULL in this
case).
Now, if they are not handling this properly, then the application will
crash (which it does).
We can do a lot, but we can't fix their bugs for them.
Jeff
|
| 146.7 | Using Telnet, not LAT??? | VMSNET::DMCFARLAND | still TurboMom[tm]... | Tue May 27 1997 10:55 | 14 |
| Jeff,
Thank you for the clarification.
I still have one last (!!!) question, which I asked in note 314.
If Reflection is running over Telnet (not LAT), should it be able
to co-exist with PW32 licensing stuff on WNT? Or does the IOCB
issue still get in the way? (Does the DECIOCB stuff still get
installed/loaded if only PW32 licensing is installed without LAT
or DECnet?)
Diane
|
| 146.8 | | SPELNK::curless | | Tue May 27 1997 11:00 | 4 |
|
It depends on WHO's telnet Reflection is running over.
Jeff
|
| 146.9 | | VMSNET::DMCFARLAND | still TurboMom[tm]... | Tue May 27 1997 11:16 | 6 |
| O.K. The possibilities I see are WNT 4.0's Telnet or Reflection's
Telnet... How can we determine which is used? And what is the
difference? Does one work and the other no...?
Diane
|
| 146.10 | | THOLIN::TBAKER | The Spirit of Apathy | Tue May 27 1997 11:30 | 4 |
| Rename all instances of PWTELNT.DLL from the machine to PWTELNT.BAK
or something like it.
Tom
|
| 146.11 | ? | VMSNET::DMCFARLAND | still TurboMom[tm]... | Tue May 27 1997 12:04 | 8 |
| Tom,
If we rename PWTELNT.DLL, then which Telnet will Reflection be
using? I am *assuming* Microsoft's (WNT 4.0)...or does Reflection
have its own version?
Diane
|
| 146.12 | | THOLIN::TBAKER | The Spirit of Apathy | Tue May 27 1997 13:59 | 13 |
| RE: .9
> Telnet... How can we determine which is used? And what is the
> difference? Does one work and the other no...?
You can determine which is used by renaming one of them or
even deleting it. This way you *know* that that one isn't
being used.
If the behavior changes after doing this then you can probably
assume that a different TELNET is being accessed.
Tom
|