I am (was) experiencing problems with my WPF application completely locking up my computer (it would freeze mouse/keyboard so no CTRL-ALT-DEL, although the hard drive could be seen to be working still) which is the exact same issue discussed in this question, however the solution there is not relevant.
I then found this question which (seems) to have proved the mustard (basically, the issue was that Comodo firewall prevents applications from accessing DLLs willy-nilly without user confirmation and since the WPF app was prevented from accessing DirectX.dll it somehow causes a system freeze before Comodo can even display the confirmation dialog).
I started writing this before I found the second question and my question was basically going to be "WTF?".
Now my question is there some way around this? Does anybody else see this sort of behaviour? I just find it hard to believe that such a small issue could bring a system to it's knees so thoroughly. More importantly I wonder if there is something I can do to prevent such things from happening to me or any of my users in the future, other than preemptively giving my applications permission in the firewall.
I had wondered if there is something unique to my application that was causing problems. I even tried creating a new application with the same UI but absolutely no logic - just a window with a few controls added that did nothing - but encountered the same freezing issue when running it. However, the application didn't freeze my system every time. Maybe it comes down to luck of timing - I was able to see the Comodo confirmation dialog sometimes and could give permission and continue.
If it is just a luck of the timing thing, I would think I would have applications freezing my system left, right and center. Maybe I don't use many apps that are built on WPF, but I use Visual Studio and it is I believe. I don't recall VS shutting down my system like this (except a few times when I tried to debug my own application). I can't swear to it, but it may be that I got lucky and granted full access to Visual Studio the first time I ran it so I never had a chance to experience this issue afterwards...
For you WPF developers, do you run into this sort of issue often in the wild?
Related
I've something really annoying happening im my code.
I've built an app in Xamarin.Forms after battling for months with the framework just to find that when I'm now done, I cannot build my app in release mode to deploy it to the Store.
The app works well in debug mode, but does not build in release mode in the UWP project. I have been struggling to find a way to build my app in release mode for 5 days. but no matter which solution I see in all the forums and the stackoverflow questions I encounter, this error won't even blink.
The error which the IDE shows when I build the app in release mode is:
Internal compiler error: Specified cast is not valid.
It does not tell me anything more than that. The IDE doesn't give me any additional error message. I have struggled for days applying solutions I find to similar to this online, but nothing works.
I have updated IDE
Updated all packages
Deleted custom renderers on the UWP project
I went through every portion of code to find where I may have made a bad cast
I tried all I could find online, but nothing works.
I usually don't ask questions on forums unless it becomes critical.
If I don't get any solution, I'll be forced to delete this project and waste the months of coding I did, and abandon Xamarin for ever and move to Flutter which has a better reputation when it comes to tooling.
First of all, please don't fume so much. We understand you are frustrated, but Caps Lock just doesn't help to make us take it more seriously. Also I know Flutter is the new "cool guy in town", but it also has its set of issues. Cross-platform development is not simple and Flutter does support only two platforms, while Xamarin.Forms have a wider reach, which is bound to bring a bit more complexity.
My first suggestion would be to change the build output more verbose in Visual Studio Options, because that could uncover the actual issue here. When it comes to release mode, the problems usually come from types which are used for reflection but the compiler does not see as used and hence throws them away. Usually these errors show up at runtime however. In your case I would suggest a few following things:
First and foremost - try to delete bin and obj folders in your project. That might help, as they sometimes get cluttered with older libraries and create conflicts.
If you have been building with a source control like Git (I hope you did), I would suggest going back to some early commits and then try to build release mode there. If the project builds, jump forward to some newer commit and try again. If it does not, try an even earlier commit. The goal of this is to pinpoint when in time was the error introduced, which should significantly help you in searching where the problem comes from.
If you didn't use any source control - first remember to do so next time. However, this time you will have to do it "the old way". Create a new project and slowly as little code from the original project, trying to do release build at each step. Hopefully this will allow you to find the culprit code and then you will be able to fix it in the original project
You can definitely post your findings here and we will be happy to help you further - like pinpointing the actual problem in the code file once you narrow it down.
I suspect your problem is coming from auto-generated XAML, so definitely make sure to focus on the .xaml files adding them one by one.
This is a tough problem, which I'm not sure how to solve. (Hence my asking here, :) ) I'm on a team of about a half dozen developers working on a WPF app. At this stage we've got a working application. Not all of the features are in it yet, but we're making progress. Everyone on the team can run the app, except for our boss who has a problem running it. When the app first starts it brings up a start screen/landing page with some buttons. All of the rest of us when we run the app we can easily click on any of the buttons. One of these buttons is labels "Orders" and takes the user to another screen where they can work on the orders. When our boss runs it, the app always crashes. However it doesn't do this at all for me, nor any of the other developers. This makes it really hard to figure out what's wrong because I can't duplicate it. I've got to admit that the problem might not be with WPF, but might instead be with the .NET framework, but at this point I don't know. I've got to start somewhere.
So ultimately the question is this, how do I determine what's failing on a different machine than my own? One that I don't have access to?
We're working with VS 2015, .NET Framework 4.5.2.
Diagnostics and logging.
Add as much diagnostic code as you can think of (and then add some more) to the code and log it to a file or the event log or a remote database or where ever. This would include call stacks, parameter values, system information etc. Then when the application crashes you can examine these logs and determine what's different between your machine and the customer's.
Without this information you're just guessing.
Quick check before you do anything else: right after a crash run Event Viewer and go to Windows Logs -> Application. You should see a number of messages related to the app and the crash including exception information that often sheds light on exactly what's going wrong.
You can put some crash report controls,
Find similar question hear exception-reporting-from-a-wpf-application
or try something from hear : CrashReporterdotNet
,
Crash nuget
This is a long shot, but easy enough to research. Your problem may have its root cause in hardware. Compare the video cards of your peers and boss. Your boss may have a card that's not within the Microsoft recommended guidelines. In WPF, there are ways to manage rendering based on the hardware.
We have a C# WPF application written in .Net 4.0, which some relatively simple data binding and grid functionality.
The styling invovles a few 'tweaks', including some hover colours and so on.
On 3 machines, out of a deployment covering 20, we are experiencing some very strange performance problems with the UI.
Effectively, after a reboot the application performs well, but after a certain (un-determined) amount of time, the UI becomes incredibly sluggish. For example, hovering the mouse over a button, and there will be a delay of up to a couple of seconds before the hover colour styling gets applied / rendered.
The machines have almost identical specifications. The graphics drivers have been updated, and the starndard setup is two NVidia Quadro 290 cards. Additoinally, we made a 'test' application containing ONLY some test UI components (including the Fluent Ribbon) and no code behind. The problem still occurs.
I have run the Windows Performance Suite to 'deep dive' the runtime WPF, and, very strangely, the UI returns to normal responsiveness if the option 'Disable Dirty Region Support' is ticked. My understanding is that, if anything, this should decrease performance further!!!
I'm at a loss of anything else to try here. A DotTrace performance analysis suggests most of the application time is spent in the PresentationFramework.dll.
[EDIT] All machines are Windows XP SP3.
[EDIT] It is possible that this occurs on all the machines and that the application is not usually allowed to run for long enough to present the problem. We are testing this now.
[EDIT] I should also point out that we are experimenting with the hotfix detailed here. It has been installed on a single machine for the moment, and I will update accordingly.
[EDIT - 24 hours later] So two machines have now been running the same code overnight. On my machine (which has never demonstrated the problem), after initial log in the application was very sluggish, but after less than a minute returned to normal. (I put that down to the machine clearly pulling things off the HDD). On the other machine (which usually demonstrates the problem), the applicaiton improved after a few seconds, but is still now sluggish in comparison to mine.
[EDIT - 48 hours later] On the test machine, the test application is now completely unresponsive (locked) after running for 48 hours. On the same machine, a lightweight 'shell' WPF application (containing a tab control, some buttons and a few panels and grids) is still running and perfectly responsive. So something in these more complex controls is causing this issue... which does indeed point back to (potentially) triggers and delegates that might be the root cause. I'll look to profile the application / controls again. In the mean time does anyone have any advice about how to ensure that the application 'cleans up' after itself at regular intervals? Because we are looking at third party controls here, so my options for editing them are limited!
Would appreciate any tips that can be provided!
try to render wpf in software mode.
in Loaded event:
HwndSource hwndSource = PresentationSource.FromVisual(this) as HwndSource;
HwndTarget hwndTarget = hwndSource.CompositionTarget;
hwndTarget.RenderMode = RenderMode.SoftwareOnly;
Something to consider when comparing performance between developer and user machines is the time it takes to load the WPF assemblies.
On a dev machine you might already have visual studio running or have previously run other WPF apps and the assemblies should all have been loaded by the time you run your app.
On a user machine, perhaps freshly rebooted, the assemblies will be loaded when the app is started, making startup significantly slower. Depending on how the app is setup there might be additional assemblies loading when various features / pages are used for the first time.
I've found the EQUATEC profiler to be useful in debugging these performance issues. Changing the profiling to "Full usual info" in the app options before building your project will profile down to the binding level.
Is there any debug/prepossessing param or any option under Windows 7 and visual studio to prevent from other processes hooking to my process?
I am writing a game for Windows, under Visual Studio, and was wondering if there is a way to disable user to hook to the game's process?
No, that's not possible. Even if you could somehow disable hooking, the user could still attach a debugger to your process and do anything they wanted. That's by design, of course: it's how you debug the problem when you write it.
Once a user has installed a program on their machine, assuming they have sufficient privileges, they have full control over that program. Trying to limit it programmatically is a fool's errand.
The solution to this program is not to be found with code. You need to investigate the built-in Windows security model, like creating limited user accounts; ask more questions about that on Server Fault.
The short answer is no.
On a Windows machine (like most other machines) a user with sufficient privileges will always have the ability to inspect and or modify the contents of your game process's address space.
That said, what sort of user(s) and or attack(s) are you looking to defend against? What assets are you looking to protect? Once you've identified these, you can start thinking about how to design your application such that attackers would have a more difficult time getting at what they want.
I'd start with reading up on Threat Modeling. Good luck!
Disabling is not possible. What you want to do is detecting byte patches, hooks or even just reading in the games memory region. But you better give up, because its not worth the time.
this problem has me baffled.
I'm writing an application which is supposed to take information from a form, pass it to a background worker which then a) writes the information to a local xml file and b) inserts the information into a remote MySQL database.
On my development machine, it seems to work flawlessly. The remote database is updated, the xml file is created if necessary and updated if it already exists. It's working.
Even if I exit out of the development environment and run the release build independantly of the IDE sandbox, the code works.
But, if I put it on another machine, the code fails and I dont understand why.
I'm currently using Visual Studio 2010 Professional on a 32 bit Windows 7 Ultimate machine.
At the moment, I'm finding that the application is stopping at a fairly specific point, which seems to be precisely where the background worker starts doing things like accessing the file system or accessing the remote database.
The project consists of a single exe file and a dll, which has a custom control I designed in it. The custom control is working fine, in that it shows what I want it to and returns the values I'm asking it to when I want it to, so it would seem that isn't to blame.
I initially thought I could be looking at a permissions problem, but running the application as administrator gets me the same response.
I've been writing using version 4 of the .NET framework, however I've just downgraded that to version 3.5 in the hopes that that may help. Both the non-development machines I've tried have been up to date - or have been brought up to date by me - prior to attempting to run the application.
I'm honestly baffled here. Any suggestions would be most welcome.
Alan
If your code fails, it most likely means there is some uncaught exception. What you should do is to log all uncaught exceptions (and probably some of the caught too) to a file, possibly using something like log4net.
I don't think we can help you beyond that.
I have written a live logging utility called Donsole for diagnosing the application in such conditions. On the developer workstation, it is very easy to diagnose using the feature-rich debugger of VS. The utility app. helps the developers exactly in this kind of scenarios where they don't have any idea what's happening inside. I recommend you download the latest build and try it for yourself. Explaining how to use this utility and how it works is beyond the scope of this answer, so I'd forward you to the codeplex page of the project.
http://donsole.codeplex.com/
This is how it looks.
Take a look at the event viewer of your operating system. Administrative Tools>Event Viewer>Windows Log>Application.