Getting "System ran out of resources. Consider disabling bitmap caching." after >~3 concurrent sessions open

[graham-m-dunn]

I will get this error, the existing sessions all continue to work, but I can't load new sessions.

A restart of IAP Desktop will fix this until it happens again.

I don't see any options to enable or disable bitmap caching (assuming that's coming from another layer of Windows).

[Window Title]
An error occurred

[Main Instruction]
Disconnected

[Content]
Because of a protocol error, this session will be disconnected. Please try connecting to the remote computer again.

System ran out of resources. Consider disabling bitmap caching.

Error code: 3334

[OK]

[jpassing]

Bitmap caching can be controlled in the connection settings:

It's disabled by default. Could you verify if that's the case for your VMs/project too?

Approximately which screen resolution are your RDP sessions using? I've seen this error happen with bitmap caching disabled, but not with less that 10 parallel sessions or so.

[graham-m-dunn]

bitmap caching is disabled in the project

I'm connecting to a remote Windows 10 instance over CRD, the display on that instance is

PS C:> [System.Windows.Forms.Screen]::AllScreens

BitsPerPixel : 32 Bounds : {X=0,Y=0,Width=3840,Height=2160} DeviceName : \.\DISPLAY1 Primary : True WorkingArea : {X=0,Y=0,Width=3840,Height=2130}

IAP desktop gets the left half of that display, so the desktops are 1920x2130.

[jpassing]

The RDP control (mstcax) consumes a pretty significant amount of virtual memory for each session, and the most likely reason for this error is that the iapdesktop.exe process ran out of virtual memory space. IAP Desktop is a 32-bit process, so it only has 2 GB of VM space to work with. In my tests, I hit that limit and git the 3334-error after opening 11 RDP sessions:

But I'm using a lower screen resolution (2560x1440) than you. That, plus memory fragmentation (if you had the process running for a while) might explain why you run into the issue much earlier.

I don't think there's a solution other than moving to 64 bit.

The only reason IAP Desktop is still 32-bit is that there are still some users running 32-bit versions of Windows 10 and I've been trying to avoid having to maintain a 32-bit and 64-bit version in parallel. But the share of 32-bit Windows versions is now pretty miniscule, so I guess we could make the 64-bit transition soon. The IAP Desktop build process already supports x64.

[jpassing]

Release 2.40 is now also available in 64-bit. I assume this should fix the problem -- if not, please re-open the issue.