We have an issue with a customer running our WPF based program. He can start the application, create a new document, navigate the menu items in a treeview to see different parts of the document, change almost (if not all) our textbox-values, add items to lists (using buttons with underlying commands), and so on, all without any problems. But if he tries to change the value of a combobox by opening the dropdown, the program becomes “not responding” and the CPU uses 100% capacity (on one core). It happens in other, random places as well, but the combobox always fails. If he uses only the keyboard and navigates to a combobox using tab, he can change its value using the arrow keys without problems. The program detects the change, and acts accordingly without any problems or performance degradation. He is just not allowed to open the drop-down…
Some info that might or might not be relevant:
- We are using DevExpress for all GUI components, with the theme “Seven” (We have tested both their version 12.1.8 and 12.2.4. The problem is the same…)
- Our program consists of a lot of textboxes, comboboxes, datagrids, listboxes, and so on. We are using dock-panels (like Visual Studio) so the user man modify the layout the way he wants. We use WPF 3D for graphical display and editing.
- Our customer is using a HP laptop with Windows 7 Professional Edition SP1 (64 bit) in Norwegian
- His resolution: 1920 x 1200
- His windows scaling factor: 100% (The one where you can scale up everything by changing the DPI)
- His installed .Net framework version: 4.0.30319.296
- He is a local administrator on his computer.
- The problem occurs regardless of install-location. (We have tried both ClickOnce, our main distribution method, and sending him the compiled release files in a compressed zip. No difference…)
- The problem is the same on both this customer’s computer, and two others in his company, so it is not just a coincidence.
- We have tried the “standard” WPF-applications-hangs-solution, by deleting a specific font cache, without success. (http://support.microsoft.com/kb/937135?wa=wsignin1.0)
- The customer lives 700 km away, so we are hoping to avoid traveling to him to debug at his computer.
- We are unable to reproduce the problem on any of our computers, even if the setup is as identical as possible. (Same Windows, same .Net, and so on…)
- We have sent him a special version of our program that logs all entries and exits of all public methods and properties in the entire application (that we have written source code for). Comparing his log file and our log file for a very simple operation that is working fine on our computers, but not on his, revealed nothing. The files looked practically the same, except his did not include the standard exit procedure that runs when hi clicks the exit-button, which of cause is as expected since he had to “kill” the application. Other than that the only difference where GUI related calls that happens at more or less random times (like a buttons command checking if it can execute or not). It is logged in both his and our logs, just at different times. (If we compare two different logs done on the same computer, we get the same results, so this is as expected.) The main thing is that all our methods both enters and exits as they should.
We are running out of options here.
- Does anyone have any suggestion to what we can do to solve this issue?
- Have you heard of other users with similar problems? (Did the solve it? How?)
- Does anyone know of a good way to debug this remotely? (Can we send him something so he may get the callstack when this happens?)
Any tips are highly appreciated!
Best regards,
Sverre
In case anyone else experience this, I’ll post the solution!
This is actually a bug in the .Net framework. More information, and link to a patch that fixes the problem, can be found here:
What could be reasons a WPF app would pin the CPU and lock the app on some computers but not others?
Thank you for all tips that lead me to the answer.
Sverre