whenever i use xaml editor designer mode, there will be an instance of XDesProc.exe at Windows Task Manager and it consume very high memory that eventually make the application hangs while i debug.
What I usually do is i will kill it at Task Manager and the program can continue running but designer view will be gone. This problem only exist at particular project but I've no idea where to trace the problem. Any wild guess?
These things to attempt or keep in mind.
Is the latest update for visual studio installed? Even if it is, one may want to run it again and try Repair.
Look at the controls on the screen in question. Can checks to determine if in design time such as DesignerProperties.GetIsInDesignMode(this) be used to circumvent code which shouldn't be run in design time? Check constructors for such places to put that check.
Remove the controls one by one until the designer behaves normally (or within a reasonable speed). That may give you a direction on the issue.
Does the same happen in Blend?
Run it in Visual Studio 2015/Blend 2015, do the same things happen? Note, if money is a factor usage of Visual Studio Community 2015 edition will work.
Related
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'm having a really strange problem that I just can't figure out. Things I compile in Visual Studio 2015 (C# projects in WinForms and WPF) will not launch outside of Visual Studio. This includes a project that is completely new and untouched. As in, create a new WPF Application, build in debug and release. Go to containing folders click on EXEs and...nothing.
When I run them I get 3 processes appearing in Task Manager (named the same as my application) than cannot be killed (through task manager or command prompt) and nothing else occurs. Nothing in event viewer that seems to correspond to the app. I've attached an instance of VS 2015 to the process and I get the following message: WpfApplication.exe has triggered a break point. Pressing Break takes me to a screen that tells me no debug information is available and pressing continue has no visible effects (I can occasionally see slight movement in the cpu % but not a lot else). Any attempt to stop debugging will cause visual studio to hang and when I end its process VS closes but its memory is not freed up according to Task Manager. All of these same things occur when building in VS2013 and attempting to run outside of VS. Everything runs just fine when run in debug mode inside Visual Studio but outside of it...not a chance.
I literally have no idea where to proceed from here. I can find no error messages or clues to point me in a direction to look. Is there something I'm missing/doing wrong? What steps can I take from here to find the source of the problem?
I've considered it may be something wrong with my computer but I want to explore the possibilities before I do something drastic like a clean install. If the prevailing opinion lies that way then I'll seek help elsewhere!
tl;dr: launching the exe of a compiled application results in no running application and no obvious error messages, how can I proceed from here?
I'm going to post an answer to this because I found out what was wrong but it probably isn't useful to have it hanging around so I'll just delete the question at some point soon.
The main lesson to remember is that the main purpose of anti virus software is to frustrate you as much as possible and if something weird is happening try turning it off briefly and see what happens. You'll probably find that things are now working correctly.
EDIT: I should restate this in a more serious fashion.
Anti virus can sometimes affect things in unexpected ways and turning it off temporarily can save you a lot of time. Keep it up to date too, mine was a version or so old and was not functioning correctly. I updated it and the deep scan now functions as expected rather than silently failing.
In in development experience, strange thing I am finding having a PC in a Bank and 3 times it has got errors and changed, and now I am finding issues in VS editors, that for example, short cuts like CTRL KU for uncommenting, and commenting multiple lines together doesn't work properly and my fast typing hands using such short cuts find it difficult to perform activities.
Also, I couldn't do "Undo" of code changes which is very very scary as I used to do a lot of code changes and save and run and again I used to successfully undo everything even though its saved. But I am finding these all not happening in this PC/organization for VS.
I tried googling out for any settings to enable for these features, but futile, as I see not much settings on these found. Could someone please help me out?
Under visual studio
GO to the Tools> Options
A window will pop up. Under Environment choose keyboard.
Make sure visual C# 2005 is selected.
For Comment/Uncomment in your xml file. Make Sure following settings are present there
You might have noticed that "Use New shortcut in" is "Global". In your case it might be something else.
Do the same for Edit.commentselection
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.
Is it possible to rise a cmd.exe processes from the silent background mode to the visible foreground so I can LOOK at them?
Problem Background:
I'm using VS2008 working with a very large solution containing C#, C++, and Fortran. Occasionally (a few times a day) when building my project the build hangs and does not allow me to do anything in VS (resulting in the need to kill the process). I have checked the output box, and there appears to be nothing helpful there.
Possible Cause:
I am thinking that maybe one of the cmd.exe windows that are spawned in the background may be waiting for some form of input, but to investigate I need to see those windows.
Search for Other Causes/Solutions:
If not this, is there a way to try to check and see if there is something else going on? Is this a problem anyone else is having. (Note: killing VS and reloading often fixes the problem first try, and the build process takes less than 15 seconds.)
If stopping and restart fixes the problem, I guess it's not an input problem.
For example when my build project halts, it's always the VB6 project or SVN that are upset. (strangely the VS projects always work fine).
Once one of these halt, they halt until they are fixed. Thus for the VB projects run and work-out what the model dialogue is saying and fix it. or on SVN it usually need a clean-up run on the directory.
The intermittent nature suggests some sort of timing issue, like a file been lock open etc.
You could attach another copy of visual studio to the cmd.exe and see where it's at. Not sure if you can get symbols for it, so it might be fun to diagnose.