Asynchronous FileStream.BeginWrite hangs in FlushWrite under "cold stress" - by Matt Davis

Status : 

  Postponed<br /><br />
		Due to current priorities, the product team decided to postpone the resolution of this item.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 283295 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 6/18/2007 12:51:00 PM
Access Restriction Public


I have a WCF service that accepts streams and saves them to disk. The file writes are done using a FileStream object opened with FileOptions.Asynchronous. When multiple requests hit the service concurrently right after startup, one or more of the requests will block forever in a FileStream.BeginWrite call. All further requests will succeed, regardless of concurrency- it's only the requests made right at app startup that block. It looks to be some kind of internal race in the async FileStream implementation- if I "prime the pump" by making a single async FileStream.BeginWrite call to a temp file when the app starts, everything works fine when I hit it with many concurrent requests. I'm not able to reproduce the behavior outside the WCF service either, so it may have something to do with what kind of thread is making the requests.
Sign in to post a comment.
Posted by Microsoft on 7/26/2008 at 12:16 AM

We were unable to reproduce the problem when running your code. We're not sure why; if this is a problem its hard to see because the repro is complicated. Mismatched begins/ends could be the culprit.


Justin Van Patten
Program Manager
Common Language Runtime
Posted by Microsoft on 6/18/2007 at 6:34 PM
Thanks for your feedback. We are sending this bug to the appropriate group within the Visual Studio Product Team for triage and resolution. Thank you, Visual Studio Product Team.
Posted by Microsoft on 6/18/2007 at 4:04 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see

Thank you,
Visual Studio Product Team