First published on TECHNET on Apr 11, 2018
Author: Kenn Guilstorf , Senior Escalation Engineer, Skype for Business
We’ve seen a large number of cases come through recently where application sharing with 32-bit Skype for Business 2015 and 32-bit Skype for Business 2016 clients (collectively, S4B) is failing intermittently. This usually happens when S4B has been running continuously for a long period of time (think many days or even weeks) and/or when Skype for Business is running on a display containing multiple monitors. The latter case is especially true when several of the existent monitors are running with a high resolution (such as running several 2k monitors, 4k monitors or above; a 2k monitor is any monitor with a horizontal resolution of 2,000 pixels or more and 4k monitors are those that support a horizontal resolution of 4,000 pixels or more).
The problem here isn’t really with S4B but rather with the 32-bit architecture. When Skype for Business 2015 or 2016 is used for application sharing, it needs to be aware of every pixel on every monitor because the end-user can move the window for the shared application to any monitor at any time. S4B keeps track of this data by creating a buffer that is large enough to accommodate the color of every pixel on every monitor. To do this, it adds up the horizontal resolution of all of the monitors and multiplies that total by the largest vertical resolution of any of the monitors. Once S4B has calculated width times height, it multiplies that total by the maximum number of color bit-planes supported by any of the monitors.
An example might describe this process better. Let’s say you have three monitors on your computer with resolutions of 800x600x8bpp, 3440x1900x32bpp, and 1900x1600x16bpp respectively. S4B adds up the horizontal resolutions (800 + 3440 + 1900 = 6140) and multiplies the total by the largest of the vertical resolutions (1900, in this case). Finally, it multiplies the product by the highest bitplane (32bpp or 32 bits-per-pixel, in this case). That equation becomes 6140 x 1900 x 4 bytes (since a byte is 8-bits, then 32 bits is 4 bytes) for a total of about 46.7 megabytes of contiguous buffer space required – that is, the buffer memory CANNOT be segmented; it must be in one long array of bytes.
In 32-bit architecture, each process only has 4GB because a 32-bit register can only address 4GB of memory space. This 4GB is then cut in half so that the process really only has 2GB and the Operating System gets the other 2GB (note that this changes if every binary in a process is large address aware – but Skype isn’t large address aware because some of the dynamic link libraries it loads aren’t).
2GB of memory seems like a lot and, when S4B is first opened, it really is. When it is first run, the Skype for Business 2015/2016 32-bit client generally uses between 100 and 300k of memory. However, Skype has a great many objects of various sizes that it needs to keep track of – things like contacts, folders, presence and so on. After the client has been running for a long period of time without being restarted (days or weeks depending on how many meetings are joined, how many IMs are sent and so on) the constant creation and destruction of these objects can cause Skype’s memory to become fragmented and the footprint of Skype to grow. After such a time, it can become impossible for Skype to allocate enough contiguous memory to satisfy the need to store the display bitmap necessary for application sharing on high definition displays. The higher the resolution of the set of monitors, the worse this will become. This is a reason why S4B (even the 64-bit version) supports only a single high-resolution monitor for application sharing scenarios.
If there is a need to use multiple 2k/4k/UHD devices or many high-resolution monitors, Microsoft recommends that customers test using 64-bit S4b (which, although still not officially supporting multiple high-resolution monitors, is not limited by 32-bit architecture) or use desktop sharing rather than application sharing; desktop sharing basically bifurcates the display device stream which requires a much smaller buffer and shouldn’t cause as many memory restriction issues.
Author: Kenn Guilstorf , Senior Escalation Engineer, Skype for Business
We’ve seen a large number of cases come through recently where application sharing with 32-bit Skype for Business 2015 and 32-bit Skype for Business 2016 clients (collectively, S4B) is failing intermittently. This usually happens when S4B has been running continuously for a long period of time (think many days or even weeks) and/or when Skype for Business is running on a display containing multiple monitors. The latter case is especially true when several of the existent monitors are running with a high resolution (such as running several 2k monitors, 4k monitors or above; a 2k monitor is any monitor with a horizontal resolution of 2,000 pixels or more and 4k monitors are those that support a horizontal resolution of 4,000 pixels or more).
The problem here isn’t really with S4B but rather with the 32-bit architecture. When Skype for Business 2015 or 2016 is used for application sharing, it needs to be aware of every pixel on every monitor because the end-user can move the window for the shared application to any monitor at any time. S4B keeps track of this data by creating a buffer that is large enough to accommodate the color of every pixel on every monitor. To do this, it adds up the horizontal resolution of all of the monitors and multiplies that total by the largest vertical resolution of any of the monitors. Once S4B has calculated width times height, it multiplies that total by the maximum number of color bit-planes supported by any of the monitors.
An example might describe this process better. Let’s say you have three monitors on your computer with resolutions of 800x600x8bpp, 3440x1900x32bpp, and 1900x1600x16bpp respectively. S4B adds up the horizontal resolutions (800 + 3440 + 1900 = 6140) and multiplies the total by the largest of the vertical resolutions (1900, in this case). Finally, it multiplies the product by the highest bitplane (32bpp or 32 bits-per-pixel, in this case). That equation becomes 6140 x 1900 x 4 bytes (since a byte is 8-bits, then 32 bits is 4 bytes) for a total of about 46.7 megabytes of contiguous buffer space required – that is, the buffer memory CANNOT be segmented; it must be in one long array of bytes.
In 32-bit architecture, each process only has 4GB because a 32-bit register can only address 4GB of memory space. This 4GB is then cut in half so that the process really only has 2GB and the Operating System gets the other 2GB (note that this changes if every binary in a process is large address aware – but Skype isn’t large address aware because some of the dynamic link libraries it loads aren’t).
2GB of memory seems like a lot and, when S4B is first opened, it really is. When it is first run, the Skype for Business 2015/2016 32-bit client generally uses between 100 and 300k of memory. However, Skype has a great many objects of various sizes that it needs to keep track of – things like contacts, folders, presence and so on. After the client has been running for a long period of time without being restarted (days or weeks depending on how many meetings are joined, how many IMs are sent and so on) the constant creation and destruction of these objects can cause Skype’s memory to become fragmented and the footprint of Skype to grow. After such a time, it can become impossible for Skype to allocate enough contiguous memory to satisfy the need to store the display bitmap necessary for application sharing on high definition displays. The higher the resolution of the set of monitors, the worse this will become. This is a reason why S4B (even the 64-bit version) supports only a single high-resolution monitor for application sharing scenarios.
If there is a need to use multiple 2k/4k/UHD devices or many high-resolution monitors, Microsoft recommends that customers test using 64-bit S4b (which, although still not officially supporting multiple high-resolution monitors, is not limited by 32-bit architecture) or use desktop sharing rather than application sharing; desktop sharing basically bifurcates the display device stream which requires a much smaller buffer and shouldn’t cause as many memory restriction issues.
Updated May 21, 2019
Version 2.0
