[BUG] Significant increase in the amount of memory used

[sat-okada]

This issue has been separated as another issue from comment #366.

To Reproduce
1.Install zoa_noreceive.zip on ProtoZoA

Memory map in initial state

2.Execute the following commands 10 times
midi endpoint send-message 0x40123456 0x00000000 -p 0 -c 1000000 -i
Memory map

Nonpaged pool has increased to 8,763,548K.

No further operations have been performed.
After 30 minutes, memory release appears to be slow.
Is this memory increase reasonable?

Installer Name or Version
・Windows.MIDI.Services.In-Box.Service.1.0.2-preview-9.250121-1820-x64.exe
・Windows.MIDI.Services.Preview.Service.Plugins.1.0.2-preview-9.250121-1820-x64.exe
・Windows.MIDI.Services.SDK.Runtime.and.Tools.1.0.2-preview-9.250121-1820-x64.exe
・USB MIDI 2.0 class driver (USBMIDI2_10.0.1.7.x64.zip)

Desktop (please complete the following information):
・OS: Windows 11 Pro Insider Preview Build 27774.rs_prerelease.250111-1221

Application Information
RamMap

[AmeNote-Michael]

Testing was performed on usbmidi2.sys driver. Issue #366 comments show that the driver maintains constant memory usage and that the driver also releases all memory when removed.

[AmeNote-Michael]

It is interesting in the data that indication memory is eventually removed after a half hour. Is this just the amount of time it takes to actually process through the 1,000,000 messages and the pool increase is the memory needed (various buffers) to process that much information through service?

[Psychlist1972]

Are you seeing the memory increase tied to a specific process?

I'll set this up and try it out after today's Canary release.

[sat-okada]

The following was inferred about this issue.
With USBMidi2, application layer and driver layer became asynchronous, which may be the cause of this behaviour.
Application sends messages to driver regardless of the device status.
Driver holds all messages and sends messages based on the device status.
This causes the messages to accumulate in driver layer.

The following describes the process tested here.

-Checking the behaviour in USBAUDIO.sys.
Install SevenColor1_noreceive.uf2 in ProtoZOA.
This device is an Alternate 0 device.
In USB Descriptor it declares that it can receive, but in fact it does not.

Run this device with USBAUDIO.sys.
Execute following command.
midi ep send 0x40903456 0x789ABCDE -p 0 -c 1000000 -i
The progress meter does not proceed.
Probably midi.exe is waiting for a request from the device.
Interrupted by Control+C.
At this time, Nonpaged pool was not changed at all.

Note that following commands are not converted to Stream MIDI, so they are not sent and the progress meter advance and the command completes.
midi ep send 0x40203456 0x789ABCDE -p 0 -c 1000000 -i

-Check behaviour in USBMidi2.sys
Run SevenColor1_noreceive.uf2 in USBMidi2.sys.
Execute following command.
midi ep send 0x40903456 0x789ABCDE -p 0 -c 1000000 -i
The progress meter goes to the end and the command completes.
Nonpaged pools show an increase.

This test shows that message request is waited for on application layer in USBAUDIO.sys.
On the other hand, USBMidi2.sys waits on driver layer and is assumed to hold messages for a considerable time until a request is received from the device.

To verify this consideration, I modified zoa_noreceive.uf2, which starts receiving when touchpad 1 is touched.
The following steps show that the messages are accumulated in driver layer.

1.Install zoa_noreceive.uf2 in ProtoZOA.
2.Monitor memory with poolmon.
cd %ProgramFiles(x86)%\Windows Kits\10\Toolz\x64
poolmon -b
3.Send a message.
midi ep send 0x40903456 0x789ABCDE -p 0 -c 1000000 -i
4. When the transmission is complete, exit midi.exe with ESC.
5. Check the memory increase with poolmon.
6. monitor ProtoZOA with midi.exe
midi ep monitor --verbose
7. Touch the ProtoZOA touchpad 1
8. A message is displayed on the monitor (midi.exe)
9. The memory usage of poolmon decreases as the message is played on the monitor.

[Psychlist1972]

@AmeNote-Michael please see above. Not sure if that changes in 27824+ with the last set of changes you made.

[AmeNote-Michael]

@sat-okada under further testing and I will send you a test driver soon, but it looks like I have managed the dropped packets on transmit side.

[AmeNote-Michael]

Spoke a little too soon, found case where driver gets locked up. Looking into it.