I'm building a Windows Forms application in C#, and testing on Windows 7 64bit revealed a silent crash.
The exact line that it fails on is this.ResumeLayout(false); near the end of the InitializeComponent() function. It's a part of the Visual Studio generated code from the Forms Designer.
There is no exception, no popup to show the program has crashed, nothing. It simply ceases to run once it hits that line. This only occurs in 64bit. Removing that line, the program runs, but cannot be maximized, and there are several other oddities related to window properties.
I've tried everything from changing build settings to using CorFlags.exe, nothing has helped. What could be the issue?
If it makes a difference, I'm using OpenTK and the GL Controls.
Had an identical problem, only in my case the software ran on some 64-bit systems and not others. For example, my laptop is a vaio pcg series bought just this year. 64-bit Windows 7 Home Edition, 1600 x 900 resolution. Program runs just fine here. My colleague has a vaio svz series, 64-bit Windows Professional with 1920 x 1080 resolution, and for some reason his kept getting the silent crash on the ResumeLayout(false) call.
Again, commenting out the this->SuspendLayout() call near the top of the INitializeComponents() sub, and the this->ResumeLayout(false) call near the bottom fixed the problem, and the program seems to run fine on both systems now.
I had the same exact problem with ResumeLayout(). It ran fine on several machines, but I had one user who had it throwing "Exception has been thrown by the target of an invocation." Not very helpful. Unfortunately they also hide some of the details from Exception.StackTrace. I consulted with our resident expert and he felt it was a resizing issue. I discovered exactly where the problem was after going to DEBUG-->Exceptions and selecting everything. I then got a break right inside a function I was using to reposition some checkboxes. For some reason this was throwing an out of range exception on this user's box...
Rectangle rect = dataGridView.GetCellDisplayRectangle(col, row, true);
The point being that selecting the break on exceptions options as I described helped me pinpoint the actual problem. The workaround that others mentioned is fine, but in this case I was able to find the root cause.
Do you use some external component?
Some OCX which is not compatible with 64bit? I had your same trouble using GdPicture.
If so, try to compile for 32bit and problem could be solved.
A simple solution to this whole ordeal was to simply remove both the offending ResumeLayout() call and its corresponding SuspendLayout() call at the beginning of the InitializeComponent() function. It seems to have had no ill effect on the layout of the window despite having a heavy number of controls on the window. Again, this was only for 64 bit machines, the issue never popped up on Windows XP or 7 32 bit.
I'm still baffled as to why the ResumeLayout() call was causing a silent crash in the first place, and still feel slightly uneasy about the "solution", but it seems to have worked.
Related
I'm having a strange issue on a program that I'm writing.
The language is C#, I'm using Win 10 x64, Visual Studio Community 2019, and the software is client/server (Sql Server Express, installed on the same machine), single thread.
The problem happens in a windows form, when selecting an icon to be displayed.
If I place a breakpoint at the start of the subroutine which manages the icon everything works fine, but when I try to remove it (the breakpoint) the entire form freezes and I can't click anywhere, moreover pushing F5 doesn't change anything and I have to stop the execution to get back to my code.
Even If I pause the execution the call stack results empty.
What do you think can cause such a behaviour?
First of all thank you very much.
I felt the need to answer because trying to show the cpu usage resulted in a change.
The Cpu usage is always very low (less than 10% at worst), but following the instructions on Microsoft Docs I put the execution (while in Cpu usage testing) in Release, as opposed to before when removing the breakpoint I left the execution in Debug, and everything runs fine.
So now the question changes:
why do it's alright in Release mode and freeze when in Debug mode but without the breakpoint?
They are the same, aren't they?
Thank you very much again.
I am designing a Windows Form app. I have an MDIParent form that loads in a maximized state, and loads its child forms in a maximized state as well. However, when I open an OpenFileDialog, or any datareader object, the MDIParent shrinks to a smaller size with all its forms and controls.
This solution Opening child form is causing mdiform to change size and shrink does not apply/work in my situation.
Also this solution https://support.microsoft.com/en-nz/help/967173/restoring-a-maximized-or-minimized-mdi-parent-form-causes-its-height-t did not work for me.
Some background: I have seen this behaviour in almost all my WinForm applications but I have never been keen to sort it out. I was able to narrow down to the causes as highlighted above when I started investigate it. Some posts are describing it as a windows bug, but it has existed for as long as the screen resolutions started going above 1024 (VS 2010) for my case. I hoped it is not just a windows bug...
I hoped it is not just a windows bug...
Feature, not a bug, but it is not one that Winforms programmers like very much. Notable is that there have been several questions about mystifying window shrinkage in the past few months. I think it is associated with the release of Win10 Fall Creators edition. It has deep changes to the legacy Win32 api layer and they've caused plenty of upheaval.
In your specific case, the "feature" is enabled by a shell extension. They get injected into your process when you use OpenFileDialog. The one that does this is very, very evil and does something that a shell extension must absolutely never do. It calls SetProcessDPIAware(). Notable is that it might have been written in WPF, it has a very sneaky backdoor to declare itself dpiAware. Just loading the PresentationCore assembly is enough. But not otherwise limited to WPF code, any code can do this and that might have been undetected for a long time.
One way to chase down this evil extension is by using SysInternals' AutoRuns utility. It lets you selectively disable extensions. But there is also a programmer's way, you can debug this in VS.
Use Project > Properties > Debug tab > tick the "Enable native code debugging" checkbox. Named slightly different in old VS versions btw. Then Debug > New Breakpoint > Function Breakpoint. Function name = user32!SetProcessDPIAware, Language = C. You can exercise this in a do-nothing WPF app to ensure that everything is set correctly. For completeness you can also add the breakpoint for SetProcessDPIAwareness, the new flavor.
Press F5 to start debugging and trigger the OpenFileDialog.ShowDialog() call. The breakpoint should now hit, use Debug > Windows > Call Stack to look at the stack trace. You typically will not see anything very recognizable in your case since the evil code lives in a DLL that you don't have a PDB for. But the DLL name and location (visible in Debug > Windows > Modules) ought to be helpful to identify the person you need to file a bug with. Uninstall it if you can live without it.
Last but not least, it is getting pretty important to start creating Winforms apps that are dpiAware so such a bug can never byte. You kick this off by declaring your app to be dpiAware so DPI virtualization is disabled. Plus whatever you need to do in your code to ensure the UI design scales properly.
I am developping an Excel addin in C#.
This addin contains panels with some buttons to open hovering Forms.
I have been notified that this feature doesn't work anymore with one computer in my company. It uses Excel Office 2016 to the latest version.
Here is what happens:
The grey box is what should be a Windows Form, but for some reasons it doesn't load up. The user clicks a button to open it, and it just stays grey with no controls, no events, no response of any kind.
Now, here is the code that should open the Form :
private void _Form_CellDoubleClick(object sender, DataGridViewCellEventArgs e)
{
// ActiveForm() returns basically a UserForm with some methods to fit my specific needs
ActiveForm().ShowMyForm(_columnButton); // --> ClickEvent
}
public void ShowMyForm(object parent = null)
{
ActiveForm().StartPosition = FormStartPosition.CenterScreen;
if (parent != null)
ComputeLocation(parent);
IntPtr handle = new IntPtr(Excel.Hwnd);
ActiveForm().Show(new WindowWrapper(handle)); // --> Shows a grey box
}
public class WindowWrapper : IWin32Window
{
private IntPtr _hwnd;
public WindowWrapper(IntPtr handle)
{
_hwnd = handle;
}
public IntPtr Handle
{
get { return _hwnd; }
}
}
I'm giving this code just in case, but I'm not really sure it is faulty.
The exact same code works perfectly fine on any other machine, and the problem occurs with any version of my addin.
I've checked it with several (stable) versions, and even with a beta version, the issue still occurs.
However, it appeared after the addin was reinstalled to a previous version on the computer. It isn't supposed to mess with anything external, but I believe it is important to point it out.
I'm using a msi installer generated with Wix 3.11 to install.
I have not modified the code, but here is what I have tried. I hope this isn't ridiculous, I'm kind of unexperienced with this:
- Uninstalling and reinstalling the addin,
- Repairing Office 2016 and then Uninstall/Reinstall when it wouldn't change anything,
- Updated the .NET version from 4.6 to 4.7.2 (the addin requires 4.6)
- Updated the graphic card drivers on the computer
In addition, I've tried to check logs to see if any kind of error was generated:
- My addin shows no error in the logs
- I've set up the Visual Studio project and started the addin on debug mode, with breakpoints and all --> no error of any kind
- I've checked the Windows Logs Events and found nothing related. I might have missed something since I'm not experienced to read them.
I have finally found a link that "did something" :
How to revert to an earlier version of office 2016
I reverted the Office version to 16.0.9330.2118, and the Forms started working as expected for around 30 minutes. Then I was notified that the issue had come back, even though nothing had been updated on the computer. It just "went wrong again". I updated Office to the latest version and it started working again until next morning.
As you can see, no error is generated, but swapping the Office version to a different one "does something". It looks like some kind of conflict with some Office libraries, but I have no idea what to do or how to deal with that.
Even though I've noticed a few topics that looked like my issue, they were all related to code and Forms management. I really believe this has nothing to do with code, even though I can't prove it for certain.
Can anybody help me with this? Even some thoughts on how to deal with this issue would be appreciated, since I'm really not comfortable with it.
EDIT:
So I kind of figured out what happened, but not entirely.
I did what #HansPassant told me and ran the VS debugger on my colleague's computer, step by step, and got it running again and again.
It appeared what was causing the issue was the ComputeLocation method (see the original content).
Basically ComputeLocation worked like this (I simplified it a bit):
private void ComputeLocation(object parent)
{
Control parentControl = (Control) parent;
Point location = parentControl .PointToScreen(new Point(0,0));
//Process location's coordinates here
location = parentControl.PointToClient(location);
ActiveForm().StartPosition = FormStartPosition.Manual;
ActiveForm().Location = location;
}
I finally noticed that the issue would happen when using PointToClient. The Form would change its location but its content wouldn't.
I got the expected behavior upon removing the call to PointToClient.
I'd like to point out that this code is actually faulty (as opposed to what I was saying in the original part), because ActiveForm() is a topMost Form and has no parent. Using PointToClient in this context is a mistake because its location is always expressed in screen coordinates, although this is not what caused my issue here : in this context, PointToClient always returns a location that is almost the same as the screens coordinates.
I ended up removing permanently the call to PointToClient, clearing the issue. The content of the form followed its container again.
I still have no clue why PointToClient causes this behavior.
A few days later, another colleague got the exact same issue whereas nothing had been updated on his computer. The addin went from running normally on an excel workbook to displaying grey boxes on the next one.
I don't know if I should mark this question as solved since I was able to remove the issue, but do not fully understand what causes it.
I believe I have found what caused the issue here.
The problem "spread" to 2 more computers in my company and I was able to fix them with the correction I made, even though I didn't know the real cause.
One more issue appeared over time: ToolStrips controls weren't displayed anymore in the add-in forms.
Ultimately, one of my coworkers had to update his Windows version and it totally wiped out all of the issues.
I checked, all 3 computers were running on Windows 10 Version 1709.
I found a link about this version issues, but I'm not entirely sure this is exactly what caused the faulty behaviors:
https://support.microsoft.com/en-us/help/4340917/windows-10-update-kb4340917
The other machines were quickly updated to the Windows 10 April 2018 upgrade, and everything is running fine again on every versions of the add-in.
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.
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)