Thanks for your help, Dave. Replacing the WOW32 DLL with the free version
worked just fine. I’ll have to look into our 16-bit to 32-bit thunk code to
make sure everything we’re doing is correct.
Thanks,
Curt
On 08/08/01, “Dave Hart ” wrote:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=NextPart_001_01C12086.306B00F0
> Content-Type: text/plain
>
> That assertion happens with a checked wow32.dll when it is asked to
> translate an invalid 16:16 protected mode address to flat 32 bit. Either
> your 16-bit code calling via a thunk, or possibly some 32-bit code
> converting input parameters, is supplying that bogus 16:16 pointer with the
> value 0x10009700 which is interpreted as selector 1000 offset 9700.
> Selector 0x1000 is invalid on its face, nearly all correct 16-bit selectors
> under NT will be (as with win3.1) ending with 0x7 or 0xf. This is true for
> all LDT selectors on the 16-bit side.
>
> If you’re passing the problematic 16:16 pointer from 32-bit code a simple
> “kb” stack trace should show you which code of yours is involved. If it’s
> coming from the 16-bit side, as you may know, debugging on NT is less
> refined. 
>
> You may be able to paper over the problem by wedging a free version of
> wow32.dll onto your checked system. I don’t recall if you’d need to match
> other free components at the same time.
>
> Dave Hart
>
>
> -----Original Message-----
> From: xxxxx@viasat.com [mailto:xxxxx@viasat.com]
> Sent: Wednesday, August 08, 2001 21:47
> To: NT Developers Interest List
> Subject: [ntdev] WOW32 limit check assertion in WinDbg
>
>
> Hello,
>
> I’m in the process of debugging my Win2k driver using WinDbg, but I keep
> getting the following assertion check from WOW32:
>
> WOW32 limit check assertion: 1000:9700 size 0 is beyond limit 13f. …
> ntdll!DbgBreakPoint:
>
> The first number before “size” is always 1000, but the one following the
> ‘:’ varies, seemingly increasing by increments of 0x1E20 each time and
> wrapping around.
>
> Execution then breaks, and I have to type ‘g’ to resume. This happens quite
> often, so much so that debugging has become painfully slow and extremely
> non-realtime. The reason why WOW32 is involved is that I’m using a 16-bit
> application to control the device. The 16-bit app is talking to a 16-bit
> DLL, which then talks to a 32-bit DLL via a 16 to 32-bit thunk, and that
> 32-bit DLL then talks to the driver. If this sounds pretty ugly, it’s
> because it is. If I had my way, everything would be 32-bit, but I don’t and
> so it’s not.
>
> My question to you is: Is there a way to make this assertion check not
> happen? I looked through the symbols in WOW32.dll, but didn’t see anything
> that jumped out at me as a way to disable assertions.
>
> Also, if anyone could point out to me the exact meaning of the assertion,
> I’d appreciate it. The statement that “size 0 is beyond limit 13f” seems to
> be false at first glance, since clearly 0 is less than 13f.
>
> One final note: If I compile the driver for a free build and run it on a
> free Win2k build, there is no indication of any problems whatsoever from
> WOW32.
>
> Thank you in advance,
> Curt
>
> —
> You are currently subscribed to ntdev as: xxxxx@davehart.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> ------=NextPart_001_01C12086.306B00F0
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
>
>
>
>
> > charset=3Dus-ascii">
> > 5.5.2654.45">
> RE: [ntdev] WOW32 limit check assertion in WinDbg
>
>
>
>
That assertion happens with a checked wow32.dll when =
> it is asked to translate an invalid 16:16 protected mode address to =
> flat 32 bit. Either your 16-bit code calling via a thunk, or =
> possibly some 32-bit code converting input parameters, is supplying =
> that bogus 16:16 pointer with the value 0x10009700 which is interpreted =
> as selector 1000 offset 9700. Selector 0x1000 is invalid on its =
> face, nearly all correct 16-bit selectors under NT will be (as with =
> win3.1) ending with 0x7 or 0xf. This is true for all LDT =
> selectors on the 16-bit side.
>
> If you’re passing the problematic 16:16 pointer from =
> 32-bit code a simple “kb” stack trace should show you which =
> code of yours is involved. If it’s coming from the 16-bit side, =
> as you may know, debugging on NT is less refined. 
>
> You may be able to paper over the problem by wedging =
> a free version of wow32.dll onto your checked system. I don’t =
> recall if you’d need to match other free components at the same =
> time.
>
> Dave Hart
>
>
>
> -----Original Message-----
>
From: xxxxx@viasat.com [> HREF=3D"mailto:xxxxx@viasat.com">mailto:xxxxx@viasat.c=
> om]
>
Sent: Wednesday, August 08, 2001 21:47
>
To: NT Developers Interest List
>
Subject: [ntdev] WOW32 limit check assertion in =
> WinDbg
>
>
>
> Hello,
>
>
> I’m in the process of debugging my Win2k driver using =
> WinDbg, but I keep
>
getting the following assertion check from =
> WOW32:
>
>
> WOW32 limit check assertion: 1000:9700 size 0 is =
> beyond limit 13f. …
>
ntdll!DbgBreakPoint:
>
>
> The first number before “size” is always =
> 1000, but the one following the
>
‘:’ varies, seemingly increasing by increments of =
> 0x1E20 each time and
>
wrapping around.
>
>
> Execution then breaks, and I have to type ‘g’ to =
> resume. This happens quite
>
often, so much so that debugging has become =
> painfully slow and extremely
>
non-realtime. The reason why WOW32 is involved is =
> that I’m using a 16-bit
>
application to control the device. The 16-bit app is =
> talking to a 16-bit
>
DLL, which then talks to a 32-bit DLL via a 16 to =
> 32-bit thunk, and that
>
32-bit DLL then talks to the driver. If this sounds =
> pretty ugly, it’s
>
because it is. If I had my way, everything would be =
> 32-bit, but I don’t and
>
so it’s not.
>
>
> My question to you is: Is there a way to make this =
> assertion check not
>
happen? I looked through the symbols in WOW32.dll, =
> but didn’t see anything
>
that jumped out at me as a way to disable =
> assertions.
>
>
> Also, if anyone could point out to me the exact =
> meaning of the assertion,
>
I’d appreciate it. The statement that “size 0 =
> is beyond limit 13f” seems to
>
be false at first glance, since clearly 0 is less =
> than 13f.
>
>
> One final note: If I compile the driver for a free =
> build and run it on a
>
free Win2k build, there is no indication of any =
> problems whatsoever from
>
WOW32.
>
>
> Thank you in advance,
>
Curt
>
>
> —
>
You are currently subscribed to ntdev as: =
> xxxxx@davehart.com To unsubscribe send a blank email to =
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> ------=_NextPart_001_01C12086.306B00F0–