[BUG] Sending messages without monitoring causes Green Screen with the USB MIDI 2.0 driver #307
Comments
Psychlist1972
added
area-usb-driver 💻
|
https://www.windowslatest.com/2024/04/06/windows-11-24h2-build-26100-causes-undocumented-issues-blocks-some-apps/ |
|
Finally installed 26100.1 (after using a network cable and several retires) Loaded that FW in an off the shelf RP2040 board , assigned the midi preview 5 driver and ran that command many times. it sens the data, Cannot reproduce the GSOD. |
|
Got two crashes now of Windows 11. (auto reboots)... but not when running the command but with that RP2040 connected after running the commands. need further check if related. Now fully reproduceable. indeed an GSOD |
|
Thank you for the repro and the crash dump, @MusicMaker.
If you want to get off the Canary train, I was told Dev channel has the ACX / USB updates in it now, so USB MIDI 2 will work on it. |
|
Indeed. noticed the Dev channel works too. Regress it with next canary build.... |
Psychlist1972
added
the
critical ‼️
|
Needs further investigation and analysis. @garydan42 thinking about it, the act of midi endpoint send-message will put driver into "run" state which will process the USB IN buffer and into double buffer. As there is no monitor or application, nothing will be feeding from double buffer. In code, the reaction is to drop data but then request to handle existing data. We should actually respond with discarding oldest data and then putting new data in buffer. What is the design pattern for this? However, does not explain GSOD - just noting what we should be doing. |
|
@garydan42 This issue is due to the "Run" state being set when a send-message occurs but nothing is reading from driver. If the device has data provided and the driver is in run state, driver will populate the double buffer stream for UMP IN with UMP data. If there is nothing reading from the UMP Data from that stream, it will eventually fill. I suspect we should just drop old data - but what is design pattern here? How do I ensure I am not conflicting on memory with other software that may be accessing stream? Is it same as when dealing with buffer for write? |
|
The pin instance shouldn't be in the run state unless someone is retrieving buffers from the cross-process queue. The code that instantiates the cross-process buffer also creates the worker threads that does the reads and callbacks. The service should be retrieving these messages, and if there are no clients listening, dropping them.
That's not to say that the cross-process queue can't become full because messages are arriving faster than they can be processed or the callback blocks or hangs. The expectation is that the newest messages are dropped in that case, not that the oldest are dropped. Architecturally there's no way to drop the oldest messages because it's a producer/consumer fifo with the reader owning removing messages from the front of the fifo and the writer adding messages to the end. To drop the oldest messages the current read position would have to be advanced by the writer thread, but the reader may be actively reading at the current read position and modifying it would lead to data corruption.
Sent from Outlook<http://aka.ms/weboutlook>
…________________________________
From: Michael Loh ***@***.***>
Sent: Monday, June 24, 2024 5:31 PM
To: microsoft/MIDI ***@***.***>
Cc: Mention ***@***.***>; Assign ***@***.***>
Subject: Re: [microsoft/MIDI] [BUG] Sending messages without monitoring causes Green Screen with the USB MIDI 2.0 driver (Issue #307)
@garydan42<https://github.com/garydan42> This issue is due to the "Run" state being set when a send-message occurs but nothing is reading from driver. If the device has data provided and the driver is in run state, driver will populate the double buffer stream for UMP IN with UMP data. If there is nothing reading from the UMP Data from that stream, it will eventually fill.
I suspect we should just drop old data - but what is design pattern here? How do I ensure I am not conflicting on memory with other software that may be accessing stream? Is it same as when dealing with buffer for write?
—
Reply to this email directly, view it on GitHub<#307 (comment)> or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOXSFVA77GNRVMTM37KQLBLZJCF3VBFKMF2HI4TJMJ2XIZLTTGBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVI2DCNRUGYZDIMBVHCSG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRUGE4DAMBQGQZDQM5ENZQW2ZNJNBQXGX3MMFRGK3ECUV3GC3DVMWVDKNRTGU2DGNJRGA3KI3TBNVS2S2DBONPWYYLCMVWIFJLWMFWHKZNKGU3DIOJSGYYTMMBYURXGC3LFVFUGC427NRQWEZLMQKSXMYLMOVS2UNRYGMZDAMJUHA2DRJDOMFWWLKLIMFZV63DBMJSWZAVFOZQWY5LFVI3DSOBVG44DQMRQGOSG4YLNMWUWQYLTL5WGCYTFNSWHG5LCNJSWG5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KM5DPOBUWG44YQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJUHE2TSNJZGQ3TDAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDEMRTG4ZDGNBTHE2YFJDUPFYGLJLMMFRGK3FFOZQWY5LFVI2DCNRUGYZDIMBVHCBKI5DZOBS2K3DBMJSWZJLWMFWHKZNKGQYTQMBQGA2DEOBTQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKRVGYZTKNBTGUYTANUCUR2HS4DFUVWGCYTFNSSXMYLMOVS2UNJWGQ4TENRRGYYDRAVEOR4XAZNFNRQWEZLMUV3GC3DVMWVDMOBTGIYDCNBYGQ4IFJDUPFYGLJLMMFRGK3FFOZQWY5LFVI3DSOBVG44DQMRQGOTXI4TJM5TWK4VGMNZGKYLUMU>.
You are receiving this email because you were mentioned.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
I have confirmed that the issue has been solved.
|
|
That's not to say that the cross-process queue can't become full because messages are arriving faster than they can be processed or the callback blocks or hangs. The expectation is that the newest messages are dropped in that case, This makes most sense, but could that not lead to a stall or a new reader process retrieving a lot of old messages ? another way could be to reset the queue when the queue overflows, but then nothing should be reading it, otherwise it could end up reading a non valid UMP message and it needs to handle to skip over corrupt data. |
|
@garydan42 I am thinking that the correct response here should be that on processing a continuous reader data input, if it looks like another message could fill cross-process queue to full, should stop continuous reader - this should cause USB stack to start to queue and use its own flow control. Then some event (maybe reads from cross-process queue check to see if continuous reader needs to be restarted) would start the continuous reader once enough space exists for servicing a max size USB message. This of course would take a bit of rework to driver - and should be made a feature request. |
|
@garydan42 @Psychlist1972 I feel that this original issue can be closed and that a new one indicating dropping USB data in large transfers should be created. Green screens no longer occurring I believe but fix may have created a new issue. UPDATE: Issue #362 may be related, and no further issue needs to be added. |
Psychlist1972
added
the
driver-august-2024-fixed
Psychlist1972
removed
the
needs-investigation 🔍
|
Closing as fixed in the August 2024 driver release. If you find it not to be when testing, will reopen. |
Describe the bug
Sending a lots of messages without monitoring causes Green Screen.
This issue only occurs if the device is running with the USB MIDI 2.0 driver (UsbMidi2.sys)
To Reproduce
Green Screen occurs.
I faced two types of Green Screen, "ATTEMPTED_SWITCH_FROM_DPC" and "KERNEL_SECURITY_CHECK_FAILURE".
Expected behavior
No Green Screen.
Installer Name or Version
Desktop (please complete the following information):
Device information, if this is with an external MIDI device:
ZOA-216.uf2.zip
The text was updated successfully, but these errors were encountered: