Can somebody explain using the checked build of XP, why one might get this assert.
This is a simple problem. Basically, we have tracked some extremely difficult problems in the storage stack to drivers (filters, 3rd party port drivers, and even our own in edge cases) which did not follow the rules. In some cases, these errors only occur during very unusual edge cases, for others, the problems are very prevelant.
Here’s a list of the checks, and why they’re done. Shorthand “Must be restored” means that the field must be restored to the original value that each filter/port/etc received the original request containing. In general, this means drivers should not modify it unless absolutely necessary, and then must restore it to the original value if they do have some need to modify it. Here’s the list:
“Must be restored”:
Srb.OriginalRequest
Srb.DataBuffer
Srb.DataTransferLength
Srb.Cdb (all bytes must be restored)
If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_PENDING) – this is illegal in general, cannot complete the SRB with SRB_STATUS_PENDING.
If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_SUCCESS), then Irp->IoStatus.Status must be a success value (NT_SUCCESS)
If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_SUCCESS), Irp->IoStatus.Information must match the value in Srb.DataTransferLength
If (SRB_STATUS(Srb.SrbStatus) != SRB_STATUS_SUCCESS), Irp->IoStatus.Status must not be a success value (!NT_SUCCESS)
If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_DATA_OVERRUN), then Irp->IoStatus.Information must be equal to Srb.DataTransferLength. This is because, by definition, the overrun indicates that there was more data available than requested. Therefore, all the buffer provided should have been filled, even though more was available.
If (Irp->IoStatus.Status == STATUS_INSUFFICIENT_RESOURCES), this indicates a low-memory condition. To ensure the class driver can properly process this, the following two fields in the SRB must also be set:
SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_INTERNAL_ERROR
Srb.InternalStatus == STATUS_INSUFFICIENT_RESOURCES
So, to get back to your question, some driver on your machine (either a 3rd party storage driver, or your own filter in the storage stack) is changing the SRB’s DataBuffer, and not restoring this field prior to completing the Irp. This is illegal, and might cause data corruption that’d be nearly impossible to track unless this assertion was firing.
If you break into the debugger at this point, you should be able to see the IRP on the stack. If you do ‘!irp ’ on the irp, you should see at least one of the device objects involved. Then, run ‘!devstack ’ and you can see what driver(s) are installed. If you are not sure, send the results of these commands to this alias, and someone on the list might already have more experience with the culprit driver.
I hope this helps explain this assertion. I think it also answered the other three posts you just sent to this reflector also. 
.
This posting is provided “AS IS” with no warranties and confers no
rights.
NOTE: Yes, I was wrong about Srb.DataTransferLength. That should indicate the amount of transferred data. Please remove that from the above list (obviously). 
.
This posting is provided “AS IS” with no warranties and confers no
rights.
Cheer thanks, very comprehensive, it is our own driver. Will take a closer
look. However this product has been around on 2K with no apparent problems?
Has there been any behaviour changes between 2K and XP in this area? P.S.
the filter is encrypting disk data.
Regards
Steve
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, January 17, 2007 6:32 PM
Subject: RE:[ntdev] Pkt->Srb.DataBuffer == Pkt->BuffPtrCpy Assert
> This is a simple problem. Basically, we have tracked some extremely
> difficult problems in the storage stack to drivers (filters, 3rd party
> port drivers, and even our own in edge cases) which did not follow the
> rules. In some cases, these errors only occur during very unusual edge
> cases, for others, the problems are very prevelant.
>
> Here’s a list of the checks, and why they’re done. Shorthand “Must be
> restored” means that the field must be restored to the original value that
> each filter/port/etc received the original request containing. In
> general, this means drivers should not modify it unless absolutely
> necessary, and then must restore it to the original value if they do have
> some need to modify it. Here’s the list:
>
> “Must be restored”:
> Srb.OriginalRequest
> Srb.DataBuffer
> Srb.DataTransferLength
> Srb.Cdb (all bytes must be restored)
>
> If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_PENDING) – this is illegal in
> general, cannot complete the SRB with SRB_STATUS_PENDING.
>
> If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_SUCCESS), then
> Irp->IoStatus.Status must be a success value (NT_SUCCESS)
>
> If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_SUCCESS),
> Irp->IoStatus.Information must match the value in Srb.DataTransferLength
>
> If (SRB_STATUS(Srb.SrbStatus) != SRB_STATUS_SUCCESS), Irp->IoStatus.Status
> must not be a success value (!NT_SUCCESS)
>
> If (SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_DATA_OVERRUN), then
> Irp->IoStatus.Information must be equal to Srb.DataTransferLength. This
> is because, by definition, the overrun indicates that there was more data
> available than requested. Therefore, all the buffer provided should have
> been filled, even though more was available.
>
> If (Irp->IoStatus.Status == STATUS_INSUFFICIENT_RESOURCES), this indicates
> a low-memory condition. To ensure the class driver can properly process
> this, the following two fields in the SRB must also be set:
> SRB_STATUS(Srb.SrbStatus) == SRB_STATUS_INTERNAL_ERROR
> Srb.InternalStatus == STATUS_INSUFFICIENT_RESOURCES
>
> So, to get back to your question, some driver on your machine (either a
> 3rd party storage driver, or your own filter in the storage stack) is
> changing the SRB’s DataBuffer, and not restoring this field prior to
> completing the Irp. This is illegal, and might cause data corruption
> that’d be nearly impossible to track unless this assertion was firing.
>
> If you break into the debugger at this point, you should be able to see
> the IRP on the stack. If you do ‘!irp ’ on the irp, you should see
> at least one of the device objects involved. Then, run ‘!devstack
> ’ and you can see what driver(s) are installed. If you are
> not sure, send the results of these commands to this alias, and someone on
> the list might already have more experience with the culprit driver.
>
> I hope this helps explain this assertion. I think it also answered the
> other three posts you just sent to this reflector also.
>
> .
>
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
There are always behavioral changes (in particular the methods for retry often get updated for better forward progress), but the main change is that we added the assertions to catch the problems. All the assertions listed will cause problems from at least Windows 2000 onwards, but good luck figuring out that the cause post-mortem.
I’m really glad these helped find a latent edge case in your software. Thanks for letting us know that these asserts were actually useful to someone!
.
This posting is provided “AS IS” with no warranties and confers no
rights.