Spontanous crash after some time of using USB ports mapped from serial

[JMS-1]

We are using USBIPD under Windows 10 WSL in combination with a Lindy 4-Port Serial to USB mapping device. After some time of working properly (sometimes hours, sometimes days) the service crashes. We tested different version but the problem stays - exception is always c0000409. For us this is real a production level issue.

Based on the windows WER report any idea what this could be? What we can try to improve or get more report on the issue?

WER.zip

[dorssel]

That's an interesting report. c0000409 means STATUS_STACK_BUFFER_OVERRUN, I've not seen it before. Unfortunately, the WER file does not provide enough information. Could you run with full logging? See https://github.com/dorssel/usbipd-win/wiki/Troubleshooting

[JMS-1]

We will try. Actually we are using this in a production-like environment which may take some effort to get a time slice for testing. And (sadly oder not) it may take some time to the error to occur - if we are lucky only a few hours after start.

Thanks

Jochen

[JMS-1]

Looks like something around asynchronous I/O. This is all we got from the log, can we get some more data somewhere? Next but real hard way would be to run it in windbg until the crash. I'm not totally sure if we are able to get this organized.

report1.txt

[dorssel]

Yes, that certainly smells like some race condition. That unfortunately means it will be hard to reproduce/debug. On the other hand, the only place where overlapped IO is used is here: https://github.com/dorssel/usbipd-win/blob/master/Usbipd/DeviceFile.cs

That's not a lot of code. I'll try to figure out what's going on here.

[dorssel]

The exact location (inside .NET) where the exception is thrown: https://github.com/dotnet/runtime/blob/v9.0.7/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolBoundHandle.WindowsThreadPool.cs#L158

[dorssel]

The only place (inside .NET) where _boundHandle is reset to null:
https://github.com/dotnet/runtime/blob/v9.0.7/src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolBoundHandle.WindowsThreadPool.cs#L119

[JMS-1]

I hope that this is really the same issue as observed "normally". Strange to me is, that it seems as if the exception is thrown in managed .NET code but the original error looks more like some native issue. But in the latest test above the service crashes after throwing the exception so at least this behaviour stays the same - maybe the exception in uncaught and leads to the service to be terminated by the .NET runtime in a way that looks like the original crash.

[dorssel]

This is on the boundary between managed and unmanaged. But it certainly is a bug, either in usbipd-win (likely) or in .NET (less likely). In any case, this is not supposed to happen. I need more time to investigate.