ASSERT in EMS port driver on checked build

NTDEV
1

While doing testing/debugging of my driver under W2k3 SP1 32-bit checked, I
am occasionally seeing the below error. I have an EMS console because my
machine is off in a computer room and an EMS console is invaluable in
selecting between different OS’s on boot, along with the ability to get a
command prompt if my driver decides to disrupt TCP routing for a remote
desktop. Has anybody seen this? Is it a clue that the serial port on my
system is somehow not compatible with sacdrv?

Since I don’t have source access to Windows, ASSERT on line 2788 of conmgr.c
is not exactly a good clue about how to fix it. A second assert, that
immediately follows if you ignore the first one doesn’t help a lot either
(see farther below). The only solutions that come to mind are: don’t use
EMS, or don’t use the fully checked OS, or perhaps try a different random
system as my testing target.

My system was doing cyclic reboot testing over the weekend when the failure
happened on cycle 322. Doing cyclic reboots has been quite helpful at
finding bugs in my (and everybody else’s) driver.

  • Jan

*** Assertion failed: NT_SUCCESS(Status)

*** Source File: d:\srvrtm\drivers\sac\driver\conmgr.c, line 2788

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread
(boipt)? b

1: kd> k 50

ChildEBP RetAddr

f7706814 8075ee4e nt!DbgBreakPoint

f7706afc f737374a nt!RtlAssert+0xba

f7706b28 f7368b17 sacdrv!ConMgrWriteData+0x60

f7706b54 f736b85c sacdrv!VTUTF8ChannelOEcho+0xd9

f7706b70 f73647cf sacdrv!VTUTF8ChannelOWrite+0x84

f7706b90 f73730b2 sacdrv!ChannelOWrite+0x7f

f7706ba4 f73730eb sacdrv!SacPutString+0x20

f7706bb0 f73740ce sacdrv!SacPutSimpleMessage+0x17

f7706bc8 f7374136 sacdrv!ConMgrEventMessage+0x52

f7706bd8 f73744fb sacdrv!ConMgrSimpleEventMessage+0x1a

f7706bf8 f737593a sacdrv!ConMgrHandleEvent+0xe9

f7706c30 80629e3a sacdrv!DispatchDeviceControl+0xc2

f7706c4c 809543e7 nt!IofCallDriver+0x64

f7706c60 809553d1 nt!IopSynchronousServiceTail+0x1f3

f7706d00 8094a874 nt!IopXxxControlFile+0x663

f7706d34 8077c225 nt!NtDeviceIoControlFile+0x2a

f7706d34 7c9497c4 nt!KiFastCallEntry+0x135

019bfe60 7c91ee30 ntdll!KiFastSystemCallRet

019bfe64 7c822569 ntdll!ZwDeviceIoControlFile+0xc

019bfec8 592d2b1b kernel32!DeviceIoControl+0x12f

019bff2c 592d19ee sacsvr!SacRegisterCmdEvent+0xb6

019bff4c 592d1fc1 sacsvr!InitSacCmd+0x89

019bff54 592d20b4 sacsvr!InitializeGlobalObjects+0x6

019bff5c 592d26ce sacsvr!Run+0x6

019bff6c 01003459 sacsvr!ServiceMain+0x96

019bffa4 77dc5eab svchost!ServiceStarter+0x191

019bffb8 7c82442c ADVAPI32!ScSvcctrlThreadW+0x21

019bffec 00000000 kernel32!BaseThreadStart+0x34

If I ignore this first ASSERT, we instantly get another:

*** Assertion failed: NT_SUCCESS(Status)

*** Source File: d:\srvrtm\drivers\sac\driver\conmgr.c, line 2788

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread
(boipt)? i

i

*** Assertion failed: pwch == (PWSTR)(String + Size)

*** Source File: d:\srvrtm\drivers\sac\driver\vtutf8chan.c, line 569

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread
(boipt)? b

b

Execute ‘.cxr F7706864’ to dump context

Break instruction exception - code 80000003 (first chance)

nt!DbgBreakPoint:

8075cc00 cc int 3

1: kd> k 50

ChildEBP RetAddr

f770684c 8075ee4e nt!DbgBreakPoint

f7706b34 f7368c21 nt!RtlAssert+0xba

f7706b60 f736b85c sacdrv!VTUTF8ChannelOEcho+0x1e3

f7706b7c f73647cf sacdrv!VTUTF8ChannelOWrite+0x84

f7706b9c f73730b2 sacdrv!ChannelOWrite+0x7f

f7706bb0 f73740d6 sacdrv!SacPutString+0x20

f7706bc8 f7374136 sacdrv!ConMgrEventMessage+0x5a

f7706bd8 f73744fb sacdrv!ConMgrSimpleEventMessage+0x1a

f7706bf8 f737593a sacdrv!ConMgrHandleEvent+0xe9

f7706c30 80629e3a sacdrv!DispatchDeviceControl+0xc2

f7706c4c 809543e7 nt!IofCallDriver+0x64

f7706c60 809553d1 nt!IopSynchronousServiceTail+0x1f3

f7706d00 8094a874 nt!IopXxxControlFile+0x663

f7706d34 8077c225 nt!NtDeviceIoControlFile+0x2a

f7706d34 7c9497c4 nt!KiFastCallEntry+0x135

019bfe60 7c91ee30 ntdll!KiFastSystemCallRet

019bfe64 7c822569 ntdll!ZwDeviceIoControlFile+0xc

019bfec8 592d2b1b kernel32!DeviceIoControl+0x12f

019bff2c 592d19ee sacsvr!SacRegisterCmdEvent+0xb6

019bff4c 592d1fc1 sacsvr!InitSacCmd+0x89

019bff54 592d20b4 sacsvr!InitializeGlobalObjects+0x6

019bff5c 592d26ce sacsvr!Run+0x6

019bff6c 01003459 sacsvr!ServiceMain+0x96

019bffa4 77dc5eab svchost!ServiceStarter+0x191

019bffb8 7c82442c ADVAPI32!ScSvcctrlThreadW+0x21

019bffec 00000000 kernel32!BaseThreadStart+0x34

2

Jan,

This ASSERT is because the OS is putting out a stream of data and the
either the pointer is NULL or the length of the data is zero. I realize
this probably isn’t enough, but this is one of those dumb asserts of the
form ASSERT(NT_SUCCESS(status));

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Jan Bottorff” wrote in message news:xxxxx@ntdev…
> While doing testing/debugging of my driver under W2k3 SP1 32-bit checked,
> I
> am occasionally seeing the below error. I have an EMS console because my
> machine is off in a computer room and an EMS console is invaluable in
> selecting between different OS’s on boot, along with the ability to get a
> command prompt if my driver decides to disrupt TCP routing for a remote
> desktop. Has anybody seen this? Is it a clue that the serial port on my
> system is somehow not compatible with sacdrv?
>
>
> Since I don’t have source access to Windows, ASSERT on line 2788 of
> conmgr.c
> is not exactly a good clue about how to fix it. A second assert, that
> immediately follows if you ignore the first one doesn’t help a lot either
> (see farther below). The only solutions that come to mind are: don’t use
> EMS, or don’t use the fully checked OS, or perhaps try a different random
> system as my testing target.
>
>
>
> My system was doing cyclic reboot testing over the weekend when the
> failure
> happened on cycle 322. Doing cyclic reboots has been quite helpful at
> finding bugs in my (and everybody else’s) driver.
>
>
>
> - Jan
>
>
>
> Assertion failed: NT_SUCCESS(Status)
>
> Source File: d:\srvrtm\drivers\sac\driver\conmgr.c, line 2788
>
>
>
> Break repeatedly, break Once, Ignore, terminate Process, or terminate
> Thread
> (boipt)? b
>
>
>
>
>
> 1: kd> k 50
>
> ChildEBP RetAddr
>
> f7706814 8075ee4e nt!DbgBreakPoint
>
> f7706afc f737374a nt!RtlAssert+0xba
>
> f7706b28 f7368b17 sacdrv!ConMgrWriteData+0x60
>
> f7706b54 f736b85c sacdrv!VTUTF8ChannelOEcho+0xd9
>
> f7706b70 f73647cf sacdrv!VTUTF8ChannelOWrite+0x84
>
> f7706b90 f73730b2 sacdrv!ChannelOWrite+0x7f
>
> f7706ba4 f73730eb sacdrv!SacPutString+0x20
>
> f7706bb0 f73740ce sacdrv!SacPutSimpleMessage+0x17
>
> f7706bc8 f7374136 sacdrv!ConMgrEventMessage+0x52
>
> f7706bd8 f73744fb sacdrv!ConMgrSimpleEventMessage+0x1a
>
> f7706bf8 f737593a sacdrv!ConMgrHandleEvent+0xe9
>
> f7706c30 80629e3a sacdrv!DispatchDeviceControl+0xc2
>
> f7706c4c 809543e7 nt!IofCallDriver+0x64
>
> f7706c60 809553d1 nt!IopSynchronousServiceTail+0x1f3
>
> f7706d00 8094a874 nt!IopXxxControlFile+0x663
>
> f7706d34 8077c225 nt!NtDeviceIoControlFile+0x2a
>
> f7706d34 7c9497c4 nt!KiFastCallEntry+0x135
>
> 019bfe60 7c91ee30 ntdll!KiFastSystemCallRet
>
> 019bfe64 7c822569 ntdll!ZwDeviceIoControlFile+0xc
>
> 019bfec8 592d2b1b kernel32!DeviceIoControl+0x12f
>
> 019bff2c 592d19ee sacsvr!SacRegisterCmdEvent+0xb6
>
> 019bff4c 592d1fc1 sacsvr!InitSacCmd+0x89
>
> 019bff54 592d20b4 sacsvr!InitializeGlobalObjects+0x6
>
> 019bff5c 592d26ce sacsvr!Run+0x6
>
> 019bff6c 01003459 sacsvr!ServiceMain+0x96
>
> 019bffa4 77dc5eab svchost!ServiceStarter+0x191
>
> 019bffb8 7c82442c ADVAPI32!ScSvcctrlThreadW+0x21
>
> 019bffec 00000000 kernel32!BaseThreadStart+0x34
>
>
>
> If I ignore this first ASSERT, we instantly get another:
>
>
>
>
>
> Assertion failed: NT_SUCCESS(Status)
>
> Source File: d:\srvrtm\drivers\sac\driver\conmgr.c, line 2788
>
>
>
> Break repeatedly, break Once, Ignore, terminate Process, or terminate
> Thread
> (boipt)? i
>
> i
>
>
>
> Assertion failed: pwch == (PWSTR)(String + Size)
>
> Source File: d:\srvrtm\drivers\sac\driver\vtutf8chan.c, line 569
>
>
>
> Break repeatedly, break Once, Ignore, terminate Process, or terminate
> Thread
> (boipt)? b
>
> b
>
> Execute ‘.cxr F7706864’ to dump context
>
> Break instruction exception - code 80000003 (first chance)
>
> nt!DbgBreakPoint:
>
> 8075cc00 cc int 3
>
> 1: kd> k 50
>
> ChildEBP RetAddr
>
> f770684c 8075ee4e nt!DbgBreakPoint
>
> f7706b34 f7368c21 nt!RtlAssert+0xba
>
> f7706b60 f736b85c sacdrv!VTUTF8ChannelOEcho+0x1e3
>
> f7706b7c f73647cf sacdrv!VTUTF8ChannelOWrite+0x84
>
> f7706b9c f73730b2 sacdrv!ChannelOWrite+0x7f
>
> f7706bb0 f73740d6 sacdrv!SacPutString+0x20
>
> f7706bc8 f7374136 sacdrv!ConMgrEventMessage+0x5a
>
> f7706bd8 f73744fb sacdrv!ConMgrSimpleEventMessage+0x1a
>
> f7706bf8 f737593a sacdrv!ConMgrHandleEvent+0xe9
>
> f7706c30 80629e3a sacdrv!DispatchDeviceControl+0xc2
>
> f7706c4c 809543e7 nt!IofCallDriver+0x64
>
> f7706c60 809553d1 nt!IopSynchronousServiceTail+0x1f3
>
> f7706d00 8094a874 nt!IopXxxControlFile+0x663
>
> f7706d34 8077c225 nt!NtDeviceIoControlFile+0x2a
>
> f7706d34 7c9497c4 nt!KiFastCallEntry+0x135
>
> 019bfe60 7c91ee30 ntdll!KiFastSystemCallRet
>
> 019bfe64 7c822569 ntdll!ZwDeviceIoControlFile+0xc
>
> 019bfec8 592d2b1b kernel32!DeviceIoControl+0x12f
>
> 019bff2c 592d19ee sacsvr!SacRegisterCmdEvent+0xb6
>
> 019bff4c 592d1fc1 sacsvr!InitSacCmd+0x89
>
> 019bff54 592d20b4 sacsvr!InitializeGlobalObjects+0x6
>
> 019bff5c 592d26ce sacsvr!Run+0x6
>
> 019bff6c 01003459 sacsvr!ServiceMain+0x96
>
> 019bffa4 77dc5eab svchost!ServiceStarter+0x191
>
> 019bffb8 7c82442c ADVAPI32!ScSvcctrlThreadW+0x21
>
> 019bffec 00000000 kernel32!BaseThreadStart+0x34
>
>