I have a piece of software that has worked fine on many machines, althoughon one machine there is a problem that appears to occur occasionaly, the MenuStrip and the ToolStrip both appear as a blank white background with a red cross over it, as a custom control would if you created a null object. This doesn't happen whilst I am debugging and I don't know how to make the problem re-occur, but it does happen. I was wondering if anyone knew what could be the problem?
Would it be the version of the .NET framework?
Thanks
This is a common occurrence when there's a GDI+ problem ("The Red X of Death"). Are you doing any custom drawing in OnPaint? Or perhaps there's a graphic resource or a glyph which is corrupt or being improperly disposed of.
Edit: I've re-read your question. You seem to have this only on one of the machines. I've googled around a bit for this, and I stumbled upon this old thread. The post at the bottom suggests that there might be an issue with Virtual Memory turned off:
We did manage to solve this - we were
seeing the problem on a device running
XP embedded. The XPe image developer
had turned off Virtual Memory and as
soon as we turned it on the problem
went away. I believe it is just a
symptom of the system running out of
memory to display the graphics (maybe
particularly if you use a lot of
double buffering)
Hope that helps.
Sounds like a symptom of an Out Of Memory Exception to me.
Edit:
Which can sometimes lead onto a System.InvalidOperationException: BufferedGraphicsContext
Are you trying to update the GUI controls from a thread other than the GUI thread? Combine the cross thread operation with an exception handler that swallowed everything and we had the behavior you describe (on a grid control, not a menustrip bar) on an app I was maintaining.
Definitively sounds like a cross-thread problem.
Make sure you use Invoke when accessing controls and/or firing events from a thread that is not the main UI thread.
Seeing this happen on just one computer of more than a 1000 that have our prouducts.
On that one computer I am seeing a .NET 3.5 program occassionally show the red X on its datagrid. And another far simpler .NET 2.0 program got the red X on its menuStrip. I only have source code for the simpler program but I can say that there isn't any user code at all which affects that component. No cross-thread stuff because nothing updates it. It's contents are set at development time with one item added to it at program load. The Red X failure was well after program load.
I was very surprised to see the problem across two different frameworks and on one program that has no data bindings. I am very wishfully hoping that the computer has its virtual memory turned off.
If it isn't that then any guidance on system parts that are shared across .NET 2.0 and .NET 3.5 would be appreciated.
Update: The user with the problem retired the computer and replaced it (which solved the problem)
Related
Background: earlier today I posted an open-source app, written in C# .NET with WinForms, on github. The first couple of people who downloaded it found that it crashed immediately on startup. Assuming I'd screwed up the distribution somehow, I posted a question here. Some helpful people downloaded the project and quickly determined that the problem was caused by a stack overflow.
So that's resolved, but the question remains: why doesn't this code blow up when I run it?
The specific problem was caused by code that attempted to resize the rightmost column of a details-mode ListView whenever the size of the window or of another column changed. A ColumnWidthChanged event handler was setting the width of a column, resulting in infinite recursion.
On my system, it works just fine (here's video). One possible explanation would be that I have a special version of WinForms (or the underlying control) that doesn't post an event change notification if the column width hasn't changed.
What I really want is to have a high degree of confidence that code that works on my system will work elsewhere. The people who answered my question seemed to have no difficulty reproducing the crash on their development systems. Did I manage to install some sort of "bulletproof edition"?
The app and library projects target either .NET Framework 4.6.1 or .NET Standard 2.0. Changing the app to target 4.7.1 had no effect. I'm using Visual Studio Community 2017, updated through 15.8.3, on a Windows 10 Pro system. This is my first attempt at a desktop C# .NET app, so I may be doing something silly.
Update: inspired by a comment from #jwdonahue I conducted an experiment: in the event handler, grab a StackTrace and check the FrameCount, recording the largest value seen. With one of the column updates enabled, I consistently see a max frame count of 414, with multiple instances of the ColumnWidthChanged event handler present. If I comment out the column update, the max count drops to 174, and I only see one instance of the event.
The stack trace from a failed run forwarded by #LexLi has 5087 entries, so it's not a simple matter of my stack limit being higher.
It might be that on your system it will eventually set the column width to the existing value. If the new value is the same as the current value then it might not trigger the changed event.
Possible reasons are:
The startup window size might be different because of different DPI.
The data might be different causing different widths on different systems.
On the failing systems the width might not converge but alternate between two values.
Theoretically it could depend on the version of the .net framework or OS.
Either way, from a practical standpoint it is best to design your software such that there are no circular calculations.
I haven't been able to find someone else who has this same issue and it is extremely frustrating. Basically, for whatever reason, Coded UI is seeing a control in a different area then where it actually is. Like this:
Bounding Rectangle for Label with "IDLE" in it is up and to the left of the control
As you can see in the picture for some reason the Bounding Rectangle is up and to the left of the selected Label with the word "IDLE" in it. This is the first time I have seen this issue and after doing like 50 googles searches I decided to come here.
First off I am using Coded UI with a Windows Forms Application (I don't know if that makes a difference), it seems to do the same thing with all Windows Forms Applications, it has worked fine for all my WPF applications.
Second, no matter how many times I record my click on a button in my application or something of the sort, running the recorded method will always click off the button (due to it thinking the button is positioned up and to the left of the control). Up and to the left seems to be the only consistent thing, how much up and to the left varies based off of where the application is on the screen.
If anyone has any ideas or something I can try please help, I have no idea what is going on. If you need anymore information feel free to ask.
Thanks
Edit for Code sample:
public class Controller : WinWindow
{
#region Constructors
public Controller()
{
SearchProperties[PropertyNames.Name] = "My Sample C#";
SearchProperties.Add(new PropertyExpression(PropertyNames.ClassName, "WindowsForms10.Window", PropertyExpressionOperator.Contains));
WindowTitles.Add("My Sample C#");
enableWindow = new EnableWindow(this);
}
#endregion
public WinEdit CommunicationSetup
{
get
{
if(communicationSetup == null)
{
communicationSetup = new WinEdit(this);
communicationSetup.SearchProperties[PropertyNames.ControlName] = "Communication";
communicationSetup.WindowTitles.Add("My Sample C#");
}
return communicationSetup;
}
}
private WinEdit communicationSetup;
}
Extra Edit:
To Click on the thing I've used this:
Mouse.Click(new Point(obj.BoundingRectangle.Location.X + 20, obj.BoundingRectangle.Location.Y + 10));
and This:
Mouse.Click(obj);
Both click up and to the left of the control, as expected since the BoundingRectangle show there as seen in the picture
Edit: To replace "right" with "left" because I'm clearly an idiot and don't know my directions lol
Edit: Here is some more pictures showing the DrawHighlight() for the button Enable on my application, sorry I have to take a ton of information out for company policy reasons which might make it a little difficult to see what everything is going on but I have to
I also moved the application around so you can see how much of a difference DrawHighlight() has when the application is moved
Application dragged further down and to the right
what is stored in the obj variable that you try to pass to Click() method?
The problem might occur because you have not enough unique properties, who may definitely describe the control. Try to add additional SearchProperties. The most valuable would be a Control ID or Automation ID. If you cannot obtain this property on the wanted control, ask your development team to add it.
Try also to debug the method. Investigate of is returned in BoundingRectangle property of the control. Try out DrawHighlight() method. It will mark the position of the control with a blue rectangle. Another option would be to use TryGetClickablePoint() method. Maybe your control's size is bigger than you can visually obtain. The last but not least: examine your control from UIMap Editor and its whole hierarchy. You might find that the control you are looking for was badly recorded.
If nothing helps, then provide some more information and results of your investigation.
Good luck with that one.
Alex
I figured a consistent way to solve my problem, thanks to #Loathing for his comments on my question. Here is how I solved it:
var ret=new Rectangle();
GetWindowRect(obj.WindowHandle, ref ret);
Mouse.Hover(new Point(ret.X, ret.Y));
I still am not sure why this works so if someone sees this and understands feel free to comment and explain, I'm a little fuzzy on what goes on with GetWindowRect.
I recently came across some interesting results when trying to debug cross browser tests between IE and chrome that similarly mimicked what you've reported. It turns out that CodedUI and IE seems to be sensitive to the display scaling. I was using a multi monitor setup with different resolutions and changing each's scaling, using mostly 125%. The control's top and left coordinates were always off in IE and I could never figure out why. After doing some math and dividing by 125%, sure enough the number matched the coordinates it was supposed to be reporting. If I tried to change the monitor scaling without restarting windows, the issue got worse and I would also miss clicks. I imagine your solution to GetWindowRect appears be DPI sensitive as well, and reporting the correct coordinates with scaling taken into account.
Link to microsoft page that loosely discusses this:
Understanding Screen Scaling Issues
I get this all the time and the only way I managed to resolve it is restarting windows (go figure yet another MS solutions with Restart of the entire OS). Anyhow, in my case, it could be working fine, but later I would RD into my desktop from a laptop and everything would go nuts with this issue. I had to restart when working directly with PC and restart again when working from RD session.
I have had this issue fairly frequently as well. In my case whenever my code tried to download a file, the browser would popup the little download bar at the bottom. From then on, all my location rectangles would be off by the height of that bar.
My guess is that it is a bug in Microsoft's CodedUI that is unable to reset itself when the window it is testing changes sizes in certain cases. I have found a lot of bugs in CodedUI, I really hope that some day they get it more stable.
The fix for my issues so far has been to close the Internet Explorer window I was using to run the tests and restart it. CodedUI can't even get this right though, so I go out and kill all iexplorer.exe processes then re-start the browser.
I have a winform within a remote desktop application that is built dynamically with a container panel for a toolbar with large (regular) buttons. The application is writen in C# and .NET 4.0. The application is viewed as it should only if I do not maximize the window (meaning restored view is fine).
Now, after RDP login - within most client computers - the application looks fine (even when we maximize and restoring). Within low resolution client computers (800x600), the buttons on the toolbar are not displayed in the right position (such as in the 1024x768 clients).
I used double buffering and it didn't help... the problem may or may not be depended on the screen resolution (it can be memory issue or something). It is not a problem of localization layout.
The following image shows the Fine and Bad states: http://imgur.com/gO4UJ,v7O9K
What can I do to resolve this issue?
OK, so in case anybody gets to this kind of case, this is the thing that made the issue:
In the form, there was an empty repaint override. The programmer that created the form was overriding the repaint with an empty method (don't know why, I guess I'll ask my team for the business logic).
How did I reproduce it in the development environment? Following Albin Sunnanbo's note, I ran the RDP application in minimized version during initialization, and I noticed that it occurs with large resolution clients also in this use case... So, I know repaint occurs while performing a window resize - and this made me suspicious about the method...
==> On a side note, I guess this is why inheritance is so bad, and going on to WPF is better. It took me 3 days to understand why this issue occurred.
The main form of my application constantly turns white in the designer when I perform the following steps:
1) Open form in design mode (All controls are visible at this point)
2) View source code for form
3) Switch back to design view
After performing the steps above, there is nothing visible in design mode for the form (not even the form). I only have this issue with one form in my application and, unfortunately it is my main form where there is a lot of logic. The workaround is to always close the form and reopen it in design mode show that all the components are visible again. I have experienced erratic errors with the designer when I am low on available memory but, this form always produces this symptom and is the only one. Any ideas as to what is causing this? I guess I could always create a new form and try moving all the controls and logic over but, I'd prefer to avoid the work if there is a simpler option.
The diagnostic is that the Paint event or OnPaint method of a control is misbehaving. These methods run at design time so you'll get an accurate visual representation of the control, the way for example that you can see the Image property of a PictureBox at design time. When such a paint event gets stuck in a loop then the entire form stops rendering properly. Beyond a simple bug, the typical reason is that the code is getting confuzzled by the non-standard runtime environment in design mode. You use the DesignMode property to ensure that such code won't cause trouble and is disabled in design mode.
Finding the misbehaving code is the challenge, especially when these are not controls you wrote yourself. Short from removing controls one by one to find the troublemaker, you can use the debugger by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one.
From personal experience, I can confirm that this is an occasional issue in both Visual Studio 2003 & 2005 whether VB or C# is used. We patched both versions to the latest service pack and even got hotfixes directly from Microsoft, neither of which resolved the issue.
In the case of VB in Visual Studio 2003, the disappearance of the controls also removed the underlying designer code so we kept having to restore the deleted code from our version control system. Very annoying - as we'd often lose code changes and have to start over.
You defiantly should check the next link:
https://weblog.west-wind.com/posts/2019/Feb/14/WPF-Hanging-in-Infinite-Rendering-Loop?fbclid=IwAR23ZnUrz7buVpFLXOX2qQin1WcifQ6h280EO25URO74NTGDkTedx1TDRb4
here's a quote from the page:
Using the StarDefinitionsCanExceedAvailableSpace Override This setting
overrides the new GridRendering behavior and basically lets you run
with a .NET 4.7.x target in your project, but keeps the old behavior
that was used in previous versions.
There is a configuration setting that can be set in app.config for
your application:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true"
/>
</runtime>
</configuration>
I can verify that using that switch lets me run 4.7.1 and not see the lock up in any scaling mode. After I
had my running version in 4.6.2 back, I once again moved up to 4.7.1
in a separate branch to try this out and sure enough the switch made
the application run targeted with 4.7.1. So there's a hacky
workaround.
It's a workaround though. This 'fix' according to Microsoft improves
grid rendering allocations, providing more precise sizing and also
improves performance and reduces memory usage. On paper this is a
great improvement, but... well, side effects 😃
I suspect this issue is not wildly common as there was not very much
info to be found about it. I think Markdown Monster makes this issue
come up because the startup sequence has a lot of window manipulation.
MM uses the MahApps UI framework which uses Window Animation and extra
rendering frames for the main window, and MM itself moves the window
offscreen for initial render and adjusts window sizing based on screen
sizes and DPI settings if the window doesn't fit on the screen or
would otherwise be offscreen. IOW, there's a bit of gyration to get
the initial window onto the screen that is more likely to hit this bug
than a simple WPF form.
So I doubt that every application needs to worry about this, but if
you have a 4.7.x WPF app it might be a good idea to try it out at
various resolutions and scale levels just to see how it fares.
We are building a WinForms based app (using .NET 3.5)
Recently i have encountered that when performing one of our application's main workflows, the application will become unresponsive in a matter of seconds, failing to properly render the UI (Shows the "Program is not responding" message).
We have reduced the issue to a suspected line of code that adds a tooltip to a label control:
ToolTip tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
I have spent the past 2 days figuring out what in this code could code any issues with the UI thread, but failed to do so.
My question is -- is it possible to use a performance profiler to gather information about code such as this? Note that the ToolTip class belongs to WinForms and i do not have the source code available for it.
Removing these lines seems to solve the issue completely.
I would like to reduce debugging efforts in the future, as this issue can manifest in other locations of our codebase.
EDIT:
The only similar reported issue i could find was this: WinForm ToolTip.SetToolTip is Hanging my application :(
You could use a program such as JetBrains DotTrace to see what is happening that actually causes the program to halt
I have the same problem, except I use a ToolTip object placed using the designer and then in the Popup event of the ToolTip I set the text for the ToolTip.
The problem only occurs on Windows 7 64-bit (I don't have a possibility to test 32-bit Win7), on 32-bit Windows XP, this works fine.
edit: i guess there was some recurrent calling of the popup event, because when i moved the tolltip setting to other place of my code, it works OK.
I know that this is an old question, but the hanging still happens on Windows 10 64-bit edition. On Windows 10 32-bit everything works fine. I have not looked at the .NET source code, but it must be a wait or something. So to overcome this problem I added the following workaround:
this.Invoke(new Action(() =>
{
tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
}
));
I was already calling this from the main thread, so according to MSDN documentation this doesn't make sense, but it releases the wait lock or something.