DTM and the ndistest headerpayloadslplit test ...

NTDEV
1

All,

I have a problem that I could really use some help with regarding the
headerpayloadsplit NDIS test offered by ndistest. I first experienced
this issue when running the DTM LWF test against a driver I’m trying to
get certified. All the DTM tests pass except for headerpayloadsplit. I
wish it was a problem with my driver, but this test fails both with or
without my LWF driver installed :confused:

I have fallen back to running this test directly using ndistest as a
simplified test case. Per the Driver Test Manager docs, I install two
“NDISTest 6.0 - CL - IM/Filter Test” adapters using drivers distributed
along with ndistest. The two miniport adapters show up under device
manager as working properly. When setting up DTM for LWF, it asks me to
select a Test Device and a Support device. I select the first NDISTest
IM/Filter adapter as the Test Device and the second IM/Filter adapter as
the Support Device, exactly the way it is described in the Driver Test
Manager docs. When running ndistest directly, I follow a similar
procedure ( first NDISTest IM/Filter adapter selected as Test Device,
None selected as Message Device and second NDISTest IM/Filter adapter
selected as Support Device ). As for a job list, I just make sure the
headerpayloadsplit test is selected along with the mandatory preconfig
and postconfig jobs. Then I click start.

The resulting headerpayloadsplit.htm file always shows the following
output …

Unexpected Failure Outside of a Test Case or Action
88888 A breakpoint was hit in the protocol driver while this test was
executing

… To investigate this, I setup a remote debug session and watched for
the debugger to display some kind of error. Unfortunately, it just spit
out ndistest log messages and didn’t hit any breakpoints. There was log
output that looked suspect, a slew of these …

NOTE: This is without EVER installing my LWF drivers on the system.

CNDTHeaderDataSplitVerifyModule::OnPacketListsIn: Packet has been
indicated with NDIS_FLAGS_PHYSICAL_ADDRESS_PRESENT flag set. But the
physical address (e93) in the Packet OOB information does not match the
physical address (e8e) for the start of packet data in the ‘Data’ MDL
which is at the virtual address XXXXXXXX.

To rule out a wonky OS install, I re-installed to a pristine state and
tried again only to get the same result. To rule out hardware problems,
I tried running the test using a clean VMWare installation and again got
the same result.

The only way I found to get this particular test to pass is to use a
real Ethernet adapter as the support device. This is contrary to the
Driver Test Manager documentation, but when a real support device is
used, both with and without my LWF installed, the suspicious debugger
output disappears and all the tests pass without any errors.

Does anyone have any insight into this? After 8 hours of pulling my hair
out, I’m all out of ideas :frowning:

Thanks in advance,

-Matthew

2

It is possible this is a known errata in 1.5. I don’t know much about the DTM side of things, but I will follow up with people who do, and get back to you here.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Matthew Grooms
Sent: Saturday, February 20, 2010 5:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] DTM and the ndistest headerpayloadslplit test …

All,

I have a problem that I could really use some help with regarding the headerpayloadsplit NDIS test offered by ndistest. I first experienced this issue when running the DTM LWF test against a driver I’m trying to get certified. All the DTM tests pass except for headerpayloadsplit. I wish it was a problem with my driver, but this test fails both with or without my LWF driver installed :confused:

I have fallen back to running this test directly using ndistest as a simplified test case. Per the Driver Test Manager docs, I install two “NDISTest 6.0 - CL - IM/Filter Test” adapters using drivers distributed along with ndistest. The two miniport adapters show up under device manager as working properly. When setting up DTM for LWF, it asks me to select a Test Device and a Support device. I select the first NDISTest IM/Filter adapter as the Test Device and the second IM/Filter adapter as the Support Device, exactly the way it is described in the Driver Test Manager docs. When running ndistest directly, I follow a similar procedure ( first NDISTest IM/Filter adapter selected as Test Device, None selected as Message Device and second NDISTest IM/Filter adapter selected as Support Device ). As for a job list, I just make sure the headerpayloadsplit test is selected along with the mandatory preconfig and postconfig jobs. Then I click start.

The resulting headerpayloadsplit.htm file always shows the following output …

Unexpected Failure Outside of a Test Case or Action
88888 A breakpoint was hit in the protocol driver while this test was executing

… To investigate this, I setup a remote debug session and watched for the debugger to display some kind of error. Unfortunately, it just spit out ndistest log messages and didn’t hit any breakpoints. There was log output that looked suspect, a slew of these …

NOTE: This is without EVER installing my LWF drivers on the system.

CNDTHeaderDataSplitVerifyModule::OnPacketListsIn: Packet has been indicated with NDIS_FLAGS_PHYSICAL_ADDRESS_PRESENT flag set. But the physical address (e93) in the Packet OOB information does not match the physical address (e8e) for the start of packet data in the ‘Data’ MDL which is at the virtual address XXXXXXXX.

To rule out a wonky OS install, I re-installed to a pristine state and tried again only to get the same result. To rule out hardware problems, I tried running the test using a clean VMWare installation and again got the same result.

The only way I found to get this particular test to pass is to use a real Ethernet adapter as the support device. This is contrary to the Driver Test Manager documentation, but when a real support device is used, both with and without my LWF installed, the suspicious debugger output disappears and all the tests pass without any errors.

Does anyone have any insight into this? After 8 hours of pulling my hair out, I’m all out of ideas :frowning:

Thanks in advance,

-Matthew

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

On 2/20/2010 7:36 PM, Jeffrey Tippet wrote:

It is possible this is a known errata in 1.5. I don’t know much
about the DTM side of things, but I will follow up with people who
do, and get back to you here.

Hi Jeffrey,

That would be fantastic! I really do appreciate it.

-Matthew

-----Original Message----- From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew
Grooms Sent: Saturday, February 20, 2010 5:05 PM To: Windows System
Software Devs Interest List Subject: [ntdev] DTM and the ndistest
headerpayloadslplit test …

All,

I have a problem that I could really use some help with regarding the
headerpayloadsplit NDIS test offered by ndistest. I first experienced
this issue when running the DTM LWF test against a driver I’m trying
to get certified. All the DTM tests pass except for
headerpayloadsplit. I wish it was a problem with my driver, but this
test fails both with or without my LWF driver installed :confused:

I have fallen back to running this test directly using ndistest as a
simplified test case. Per the Driver Test Manager docs, I install two
“NDISTest 6.0 - CL - IM/Filter Test” adapters using drivers
distributed along with ndistest. The two miniport adapters show up
under device manager as working properly. When setting up DTM for
LWF, it asks me to select a Test Device and a Support device. I
select the first NDISTest IM/Filter adapter as the Test Device and
the second IM/Filter adapter as the Support Device, exactly the way
it is described in the Driver Test Manager docs. When running
ndistest directly, I follow a similar procedure ( first NDISTest
IM/Filter adapter selected as Test Device, None selected as Message
Device and second NDISTest IM/Filter adapter selected as Support
Device ). As for a job list, I just make sure the headerpayloadsplit
test is selected along with the mandatory preconfig and postconfig
jobs. Then I click start.

The resulting headerpayloadsplit.htm file always shows the following
output …

Unexpected Failure Outside of a Test Case or Action 88888 A
breakpoint was hit in the protocol driver while this test was
executing

… To investigate this, I setup a remote debug session and watched
for the debugger to display some kind of error. Unfortunately, it
just spit out ndistest log messages and didn’t hit any breakpoints.
There was log output that looked suspect, a slew of these …

NOTE: This is without EVER installing my LWF drivers on the
system.

CNDTHeaderDataSplitVerifyModule::OnPacketListsIn: Packet has been
indicated with NDIS_FLAGS_PHYSICAL_ADDRESS_PRESENT flag set. But the
physical address (e93) in the Packet OOB information does not match
the physical address (e8e) for the start of packet data in the ‘Data’
MDL which is at the virtual address XXXXXXXX.

To rule out a wonky OS install, I re-installed to a pristine state
and tried again only to get the same result. To rule out hardware
problems, I tried running the test using a clean VMWare installation
and again got the same result.

The only way I found to get this particular test to pass is to use a
real Ethernet adapter as the support device. This is contrary to the
Driver Test Manager documentation, but when a real support device is
used, both with and without my LWF installed, the suspicious debugger
output disappears and all the tests pass without any errors.

Does anyone have any insight into this? After 8 hours of pulling my
hair out, I’m all out of ideas :frowning:

Thanks in advance,

-Matthew

— NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Matthew, your situation is indeed covered by a known errata in WLK 1.5. I’m told that if you are running these tests as part of the DTM, it will automatically pick up the latest errata filter and ignore the error message. If you are running NDISTest as a standalone app, then you’ll just have to ignore it.

The errata covers this message when running HeaderPayloadSplit when the target is a filter driver:

Unexpected Failure Outside of a Test Case or Action 88888 A breakpoint
was hit in the protocol driver while this test was executing

Sorry for making you pull your hair out on this.

-----Original Message-----
From: Matthew Grooms [mailto:xxxxx@shrew.net]
Sent: Sunday, February 21, 2010 9:32 PM
To: Windows System Software Devs Interest List
Cc: Jeffrey Tippet
Subject: Re: [ntdev] DTM and the ndistest headerpayloadslplit test …

On 2/20/2010 7:36 PM, Jeffrey Tippet wrote:

It is possible this is a known errata in 1.5. I don’t know much about
the DTM side of things, but I will follow up with people who do, and
get back to you here.

Hi Jeffrey,

That would be fantastic! I really do appreciate it.

-Matthew

-----Original Message----- From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew Grooms
Sent: Saturday, February 20, 2010 5:05 PM To: Windows System Software
Devs Interest List Subject: [ntdev] DTM and the ndistest
headerpayloadslplit test …

All,

I have a problem that I could really use some help with regarding the
headerpayloadsplit NDIS test offered by ndistest. I first experienced
this issue when running the DTM LWF test against a driver I’m trying
to get certified. All the DTM tests pass except for
headerpayloadsplit. I wish it was a problem with my driver, but this
test fails both with or without my LWF driver installed :confused:

I have fallen back to running this test directly using ndistest as a
simplified test case. Per the Driver Test Manager docs, I install two
“NDISTest 6.0 - CL - IM/Filter Test” adapters using drivers
distributed along with ndistest. The two miniport adapters show up
under device manager as working properly. When setting up DTM for LWF,
it asks me to select a Test Device and a Support device. I select the
first NDISTest IM/Filter adapter as the Test Device and the second
IM/Filter adapter as the Support Device, exactly the way it is
described in the Driver Test Manager docs. When running ndistest
directly, I follow a similar procedure ( first NDISTest IM/Filter
adapter selected as Test Device, None selected as Message Device and
second NDISTest IM/Filter adapter selected as Support Device ). As for
a job list, I just make sure the headerpayloadsplit test is selected
along with the mandatory preconfig and postconfig jobs. Then I click
start.

The resulting headerpayloadsplit.htm file always shows the following
output …

Unexpected Failure Outside of a Test Case or Action 88888 A breakpoint
was hit in the protocol driver while this test was executing

… To investigate this, I setup a remote debug session and watched
for the debugger to display some kind of error. Unfortunately, it just
spit out ndistest log messages and didn’t hit any breakpoints.
There was log output that looked suspect, a slew of these …

NOTE: This is without EVER installing my LWF drivers on the system.

CNDTHeaderDataSplitVerifyModule::OnPacketListsIn: Packet has been
indicated with NDIS_FLAGS_PHYSICAL_ADDRESS_PRESENT flag set. But the
physical address (e93) in the Packet OOB information does not match
the physical address (e8e) for the start of packet data in the ‘Data’
MDL which is at the virtual address XXXXXXXX.

To rule out a wonky OS install, I re-installed to a pristine state and
tried again only to get the same result. To rule out hardware
problems, I tried running the test using a clean VMWare installation
and again got the same result.

The only way I found to get this particular test to pass is to use a
real Ethernet adapter as the support device. This is contrary to the
Driver Test Manager documentation, but when a real support device is
used, both with and without my LWF installed, the suspicious debugger
output disappears and all the tests pass without any errors.

Does anyone have any insight into this? After 8 hours of pulling my
hair out, I’m all out of ideas :frowning:

Thanks in advance,

-Matthew

— NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

On 2/22/2010 8:24 PM, Jeffrey Tippet wrote:

Matthew, your situation is indeed covered by a known errata in WLK
1.5. I’m told that if you are running these tests as part of the
DTM, it will automatically pick up the latest errata filter and
ignore the error message. If you are running NDISTest as a
standalone app, then you’ll just have to ignore it.

The errata covers this message when running HeaderPayloadSplit when
the target is a filter driver:
> Unexpected Failure Outside of a Test Case or Action 88888 A
> breakpoint was hit in the protocol driver while this test was
> executing

Sorry for making you pull your hair out on this.

Thanks so much! I was running it in both the DTM and stand alone. Maybe
I just need to update the errata filters manually somehow.

Thanks again,

-Matthew

6

I have also seen this error and was hoping that you would find a sloution.

I saw that the DTM filters were updated yesterday. They can be downloaded from the winqual site on the first page of the “Create a Hardware Logo Submission” page. The link is on the top left “WLK Updated Filters”. There is a readme file in the cab file you download which contains directions for installing the updated filters.

I installed the new filters and reran the NDSI LWF test and it still fails with the same error.

I’m going to report this to the winqual folks to see if they can tell me exactly how to get the test to run without errors.

-Ron

7

It turns out that the latest DTM filters do handle this problem. The error still shows up after you finish running the tests. However, if you suspect that this problem may be ignored and go ahead and use the DTM Controller to create the submission package the failure disappears from the Job Monitor list. If you then use the DTM Log File Viewer on the submission package file (.cpk) there is a note saying that the error will always occur and it has been ignored. The submission will not fail because of this HeaderPayloadSplit test failure.

-Ron