Performance issue with MFC dialogs on Windows Server 2025 compared to Windows Server 2019

Question

Description

We are observing significantly slower performance while loading MFC dialogs which has controls like CComboBox, on Windows Server 2025 compared to Windows Server 2019. For e.g., while inserting more number of items into the MFC CComboBox it is taking considerably long time, when compared to Server 2019, here we are using the same 32-bit application binary and the same VC++/ MFC runtime built with Visual Studio 2015 to compare the performance on both Server 2025 and Server 2019. The control under test is a CComboBox configured as a drop-down, sort as true and Owner Draw as NO inserted strings (140k records) are variable in content/length and all tests were executed on virtual machines. The same executable is used across the server versions without code changes, and the application behaves acceptably on Windows Server 2019 (around 10 seconds) but is noticeably slower, i.e. 2 times slower on Windows Server 2025 (around 30 seconds) for the same combo-box loading scenario. Apparently on investigation, it looks the CComboBox::InsertString is where it is taking long time. 

Impact

This affects user-facing workflows in our application where a large number of items must be loaded into an MFC dialogs say in the CComboBox control. On Server 2019 the same binary performs acceptably, but on Server 2025 the delay is significantly more noticeable.

 

Test application - 

To isolate the issue, we created a dedicated test application with MFC dialog that performs the following sequence, which can be run on Server 2025 and 2019 to mark observations:

1. A loop that performs only CComboBox::InsertString 100,000 times.
2. Invalidate and UpdateWindow() after insertion completes.

There is no additional application logic inside the measured insertion loop other than InsertString. The purpose of the test is to isolate combo-box insertion performance only. We are providing the sample code here for your consumption, we can also provide and logs generated on our side if needed.

 

Systems tested - we have tested the above test application on -

• Windows Server 2019 Standard, build 17763, 32-bit EXE, 4 logical CPUs.
• Windows Server 2025 Standard 24H2, build 26100, 32-bit EXE, 2 logical CPUs.

All are same CPU family: Intel Xeon Gold 6354 @ 3.00 GHz, and the application bitness is 32-bit in all cases.

Observed timings -

For the first 100,000-item load, the InsertString loop timings are:

• Windows Server 2019: approximately 21231 milliseconds
• Windows Server 2025: approximately 34912 milliseconds

Questions

We would like Microsoft to help confirm the following:

1. Is slower CComboBox::InsertString behavior on Windows Server 2025, compared to Windows Server 2016, a known and intentional change or a regression in the behaviour of combo-box/ other common-controls?
2. Is there any known resolution / fix, or any recommended settings for mitigation of the issue on Server 2025? It could be some suggestions on code changes in the way we use the controls in MFC dialogs on our side or some suggestions around the configuration / settings on the environment. 
3. Are there additional diagnostics or traces you would like us to collect to help analyse this issue? Can you please send the steps regarding those.Description We are observing significantly slower performance while loading MFC dialogs which has controls like CComboBox, on Windows Server 2025 compared to Windows Server 2019. For e.g., while inserting more number of items into the MFC CComboBox it is taking considerably long time, when compared to Server 2019, here we are using the same 32-bit application binary and the same VC++/ MFC runtime built with Visual Studio 2015 to compare the performance on both Server 2025 and Server 2019. The control under test is a CComboBox configured as a drop-down, sort as true and Owner Draw as NO inserted strings (140k records) are variable in content/length and all tests were executed on virtual machines. The same executable is used across the server versions without code changes, and the application behaves acceptably on Windows Server 2019 (around 10 seconds) but is noticeably slower, i.e. 2 times slower on Windows Server 2025 (around 30 seconds) for the same combo-box loading scenario. Apparently on investigation, it looks the CComboBox::InsertString is where it is taking long time.  Impact This affects user-facing workflows in our application where a large number of items must be loaded into an MFC dialogs say in the CComboBox control. On Server 2019 the same binary performs acceptably, but on Server 2025 the delay is significantly more noticeable.   Test application -  To isolate the issue, we created a dedicated test application with MFC dialog that performs the following sequence, which can be run on Server 2025 and 2019 to mark observations:
   1. A loop that performs only CComboBox::InsertString 100,000 times.
   2. Invalidate and UpdateWindow() after insertion completes.
   There is no additional application logic inside the measured insertion loop other than InsertString. The purpose of the test is to isolate combo-box insertion performance only. We are providing the sample code here for your consumption, we can also provide and logs generated on our side if needed.   Systems tested - we have tested the above test application on -
   • Windows Server 2019 Standard, build 17763, 32-bit EXE, 4 logical CPUs.
   • Windows Server 2025 Standard 24H2, build 26100, 32-bit EXE, 2 logical CPUs.
   All are same CPU family: Intel Xeon Gold 6354 @ 3.00 GHz, and the application bitness is 32-bit in all cases. Observed timings - For the first 100,000-item load, the InsertString loop timings are:
   • Windows Server 2019: approximately 21231 milliseconds
   • Windows Server 2025: approximately 34912 milliseconds
   Questions We would like Microsoft to help confirm the following:
   1. Is slower CComboBox::InsertString behavior on Windows Server 2025, compared to Windows Server 2016, a known and intentional change or a regression in the behaviour of combo-box/ other common-controls?
   2. Is there any known resolution / fix, or any recommended settings for mitigation of the issue on Server 2025? It could be some suggestions on code changes in the way we use the controls in MFC dialogs on our side or some suggestions around the configuration / settings on the environment. 
   3. Are there additional diagnostics or traces you would like us to collect to help analyse this issue? Can you please send the steps regarding those.

Answer 1

We have verified the configuration on both the systems 2019 and 2025 with same configuration i.e. Logical CPU's and Total RAM is same but execution time is increased in 2025 as mentioned in the problem. We have also tried the suggested option it is not meeting the 2019 execution time but we could see slight improvement with the suggested option.

Answer 2

Hello SAMUDRALA Suresh,

The increased execution time during CComboBox InsertString loops is caused by additional Win32 user-mode message processing and UI Automation hook evaluations introduced in the updated user32 and common controls subsystem on Windows Server 2025, which compounds significantly over one hundred thousand insertion calls when automatic sorting is enabled without pre-allocated storage. Furthermore, your Server 2025 test virtual machine is allocated only two logical CPUs compared to four on Server 2019, which impacts thread scheduling and heap reallocations during intensive UI message loops.

To mitigate this bottleneck at the application level, send a CB_INITSTORAGE message to the combo box control before starting the loop to pre-allocate memory for the items and text buffers, and wrap the insertion loop between SetRedraw FALSE and SetRedraw TRUE calls to suppress layout recalculations until population completes. If feasible, pre-sorting your data array in memory and disabling the CBS_SORT control style will also remove the quadratic string comparison overhead during each insert call. For diagnostic profiling, you can run Windows Performance Analyzer with the User Interface and User-Mode Process Performance tracing profiles enabled to record the exact message dispatch latency within user32.dll during the loop.

Tracy Le.