none
What causes System.OperationCanceledException?

    Question

  • I have a C# app that very occasionally throws System.OperationCanceledException from a call to FileStream.EndRead.  The ONLY reasons that I can find that cause this exception are either the thread that opened the stream terminates, or some sort of "cancel" operation is performed on the file handle.

    I can't find any explicit description of what the candidate cancel operations are.  I'm not loading Microsoft.VisualBasic.dll, so none of the methods that take UICancelOption would seem to be the culprits.

    I have confirmed that thread termination is not the issue. The file is opened on the main UI thread.

    Can anyone offer suggestions about what condition might cause this exception?

    FWIW, the file stream is for a USB character device.  The problem seems to occur when the device is either inserted or removed.  If I fail to close the stream, I normally expect (and get) System.IO.IOException.    Unfortunately, the exception is not reproducible but definitely there.  It seems to be confined to Windows 7.
    Friday, March 12, 2010 10:25 PM

Answers

  • If I remember correctly, it is considered good practice for a UMDF driver to attempt to cancel all outstanding IO if a device is removed unexpectedly (in response of OnSurpriseRemoval through a call to IWDFRemoteTarget::Stop (WdfIoTargetCancelSentIo) ). This could explain why your IO request appears to be cancelled.

    At to why the issue only seems to appear on Windows 7, I don't know for sure. If this is confined to a single device, it seems plausible that the driver got rewritten in the Vista/Windows 7 time frame, and that the new driver reacts differently when you yank the device.

    HTH
    --mc
    • Marked as answer by SamAgain Monday, March 22, 2010 3:14 AM
    Saturday, March 13, 2010 12:39 AM
  • Yes, it would be hard to prove and probably pointless. What I mean is that since it is possible for a driver to cancel all outstanding IO in an emergency (and a device being yanked qualifies), it would be wise to expect that kind of exception and handle it properly, if possible.

    HTH
    --mc

    • Marked as answer by SamAgain Monday, March 22, 2010 3:13 AM
    Thursday, March 18, 2010 7:49 PM

All replies

  • If I remember correctly, it is considered good practice for a UMDF driver to attempt to cancel all outstanding IO if a device is removed unexpectedly (in response of OnSurpriseRemoval through a call to IWDFRemoteTarget::Stop (WdfIoTargetCancelSentIo) ). This could explain why your IO request appears to be cancelled.

    At to why the issue only seems to appear on Windows 7, I don't know for sure. If this is confined to a single device, it seems plausible that the driver got rewritten in the Vista/Windows 7 time frame, and that the new driver reacts differently when you yank the device.

    HTH
    --mc
    • Marked as answer by SamAgain Monday, March 22, 2010 3:14 AM
    Saturday, March 13, 2010 12:39 AM
  • This certainly seems plausible.  It would explain both the exception and its rarity.  Could be tough to prove w/o kernel debugging.
    Tuesday, March 16, 2010 2:28 AM
  • Yes, it would be hard to prove and probably pointless. What I mean is that since it is possible for a driver to cancel all outstanding IO in an emergency (and a device being yanked qualifies), it would be wise to expect that kind of exception and handle it properly, if possible.

    HTH
    --mc

    • Marked as answer by SamAgain Monday, March 22, 2010 3:13 AM
    Thursday, March 18, 2010 7:49 PM