The feature works the same for any of the API calls; if the handle is in the OpenDetached state internally, it is eligible for reattachment, and functions that correctly SetLastError() will return ERROR_DEVICE_REMOVED. I verified that PacketSendPacket correctly sets the last error in this way, so if you are getting ERROR_OPERATION_ABORTED, then I think there must just have been a race condition between 2 checks of OpenStatus. I can fix that for the next release, but for now, try treating ERROR_OPERATION_ABORTED as a transient error; wait for 100ms or so and try again.

For the record, here's what I think is happening:

1. NPF_Write calls NPF_StartUsingOpenInstance with a requested status level of OpenRunning (required in order to send on the adapter).
2. The handle is actually OpenDetached, so NPF_StartUsingOpenInstance returns false, but it has already unlocked the OpenStatus data member by the time it returns.
3. Meanwhile, the adapter is reattached, and the handle is reattached to the new filter module, setting OpenStatus to OpenAttached
4. NPF_Write sees the false return of NPF_StartUsingOpenInstance and checks OpenStatus itself to determine which error code to return. The value is OpenAttached, which is not OpenDetached, so the default error status is used, not the special ERROR_DEVICE_REMOVED status.

We could try again within NPF_Write if the OpenStatus appears to be sufficient to do the operation, but for now the cleanest approach would be to change the strict equality test for OpenDetached into a broader test for "at least OpenDetached", meaning that if it's not an unrecoverable state (OpenClosed), then we return ERROR_DEVICE_REMOVED and allow the user to try again.