What happens internally when WdfRequestMarkCancelableEx returns STATUS_CANCELLED?

The reason why WdfRequestUnmarkCancelable would return STATUS_CANCELLED is easy to understand - it does so if the request is being canceled when we call that function. In other words, it means, "it's too late to cancel it, the cancellation is already going."

But what happens internally when WdfRequestMarkCancelableEx returns STATUS_CANCELLED?

That function is supposed to set up cancellation, but how can a request be canceled if we haven't set up the cancellation yet?

The thread that initiated the request is terminating, for example. You are setting up your driver’s cancel callback routine, not setting up ‘cancellation for the request’.

@Mark_Roddy , what am I missing? If I check the documentation, it says:

STATUS_CANCELLED The I/O request has been canceled.

Is WDFREQUEST tied in to a thread?

Yes, it says that. An IO request can be explicitly cancelled, but it also can be implicitly canceled by, for example, thread termination. That is the most likely case.

A WDFREQUEST is tied to a thread if it represents a user mode IRP. It might also have a thread associated with it if a kernel mode component set it up that way. But I think you are not asking the right questions.

Your initial confusion was over why WdfRequestMarkCancelableEx could return STATUS_CANCELLED, and that can happen because your driver can be processing the request on one thread while the IRP, for whatever reason, is being cancelled on another thread.

If you create the request in your driver, if it is not being handed to you in one of the IO request processing event callbacks, WdfRequestMarkCancelableEx is not going to return STATUS_CANCELLED.