I can set the trace using code such as:
xmlns:trace="clr-namespace:System.Diagnostics;assembly=WindowsBase"
trace:PresentationTraceSources.TraceLevel=High
I can also set the debug settings in Options->Debugging->Output Window->Data Binding.
But I cannot see the trace information as it occurs in design-time.
You might ask why I want to do this. The design-time execution is not the same as the runtime execution, even when I have made the best effort to keep things running the same way. Seeing these traces would be a huge help.
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.
This scenario has come up before and I'm wondering if there is any way I can determine where the actively running form is executing within code? The problem is when I inherit a very large application which I'm not totally familiar with yet and I have it running through VS.NET 2010. I might have a particular screen up and go "geeze it would be nice if I could start debugging when I do 'x'".
If this was a simple form with some buttons I wouldn't even bother asking here; I'm not that novice. But the time consuming task is when I look at a tabbed screen in a large multi-project solution with drag and drop capabilities, right click options, etc. and have to spend 5-10 minutes tracking down where to place a breakpoint to debug.
What I'm wondering is if there is a way to have the WinForms app running via IDE and do 'something' that tells VS.NET on the next action break into the code (obviously without a breakpoint because I don't know where to place one yet). This would save me a ton of time trying to track down which event is occurring in a not so simple form or series of forms.
I hope this makes sense...
Thanks!
Yes, that's somewhat possible. When you use Debug + Break All then the 99.9% odds are that you don't break into code that's part of the project. A Winforms app is normally idle, pumping the message loop and waiting for Windows to tell it that something happened. You'll break at the Application.Run() statement.
The trick to then use Debug + Step Over. The program resumes running like normal. Then give a UI command (do 'x' in your question) and the debugger will break at the first statement of real code, typically at the start of the event handler for that command. It isn't exactly guaranteed that that code would be relevant, you might break at a MouseMove event handler for example. So YMMV.
I'm trying to debug an issue that happens on service startup. Trying to attach while things are running is failing, windbg times out with an error about a link lock. I think that the error occurs before I have a chance to attach. A sleep might let me attach, but is there a more elegant solution?
I'd like to start up the debugger first thing as the service starts. C# has a Debugger.Launch() method to start a debugger at runtime. Is there an equivalent C call that can be used without .net? Something I could just drop in the start routine.
I can't call DebugBreak because at the time the service has started I'm not under a debugger.
Sleep is certainly a viable approach. It's crude yet effective. Somewhat less crude is to use a good logging framework to output diagnostics. With a sufficiently capable logging framework this can be very effective.
A WPF application. Debugging. Stop on break point.
After few seconds Visual Studio (2008) spontaneously aborts the application execution.
It is never mind what I do after stop on break point: even if I do nothing.
With very simple test WPF application everything is OK with debugging.
Any ideas?
When an application aborts that quickly without warning it's usually the result of a stack overflow in the process. This makes it difficult (if even possible) to do tear downs operations like bringing up Dr Watson.
One thing I didn't quite understand is if the application or VS is suddenly stopping.
If it's the application there is likely a StackOverflow occurring in such a way that VS can't trap the exception. Try disabling Just My Code debugging, turn off implicit function evaluation and break on first chance exceptions. That should hopefully help reveal the problem.
The problem was solved.
To solve the problem the debug settings must be changed:debug->exceptions: and check on exceptions boxes (I checked on C++ and CLR).
(source: ggpht.com)
Result: I can see exception that I didn't see before and I can normally debug my application.
The reason was incorrect vcshost.config file name (my fault).
I know that running applications in DEBUG (build configuration) thru the visual studio adds a level of overhead but I have a WPF application that I am testing out that is painfully slow in its execution and other functions such as drag/drop of items. When I run the application in Release mode it performs like one would expect, very quickly and without hesitation. I've set up no special debugging parameters or any other watches, settings or breakpoints that would interrupt the application.
Has anyone else run across an issue like this or is there possibly just some setting that can be adjusted? It's not really an issue more of a why is this happening...
thanks.
The garbage collector is much less aggressive in debug mode.
Try watching the memory usage in task manager, the VM Size column is often the most useful.
See if during the slow operations a lot of memory gets released - this will indicate that the collector hasn't bothered doing much work for a while and then has had to kick in a do a larger clean up.
You might check your Output and Immediate windows. You're might be getting a lot of messages thrown in there, especially if you're getting binding errors.