I've been writing an app using the awesome new Razor view engine and for the most part, things have been great.
One issue I keep running into, however, is that if I should happen to write invalid code, such as referencing a null property or even a non existent property, rather than throwing an error, something happens in the background that causes the browser to wait and wait and wait and if I do not cancel the browser's request quick enough, IIS will simply hang.
It seems as if it enters some sort of loop. CPU usage goes up (though not terribly high) and restarting IIS via either GUI or iisreset command seems to take abnormally long (presumably while it waits for the process to safely shutdown).
This also happens for other invalid code scenarios such as failing to close a code block with a closing brace.
I notice this behavior on more than one machine.
Any ideas if this is a known issue or have I mis configured something?
Thanks!
I found the problem. I had installed a package via NuGet called "Razor Debugger" and apparently this plugin was intercepting Razor errors somehow, and was consequently not showing them.
Removing that package now allows Razor to work properly. What a relief.
Steer clear of this library.
Related
I was in the middle of developing an update to my Xamarin Forms app, but when I debugged it on my iPhone, it crashed immediately on startup with the following message:
Assertion failure in -[UIApplication_runWithMainScene:transitionContext:completion:], /BuildRoot/Library/Caches/com/apple.xbs/Source/UIKit/UIKit-3600.5.2/UIApplication.m:3679
It was previously working fine, but now I can't run the app on my phone anymore without this crash. I have rebuilt several times and deployed from different computers, but nothing helps. How do I fix this issue?
Edit:
Before this started occurring, I had made some additions to the code. Unfortunately, after removing all of my changes, this issue is still plaguing further development. Any help or resource that might lead me to a solution will be greatly appreciated.
After some deep searching, it turns out that I mistakenly removed a part of my Application's constructor that initialized the MainPage. As a result, MainPage remained null. The framework probably tried to call a method or access a property without checking if the reference was null, causing the error. I'm not sure how long that mistake has been there.
This can also happen if you are not quick to launch a view. Avoid calling APIs or other lengthy processes before a page is displayed for the first time. You may do that in parallel but not in the same thread that launches the page.
I'm now working on some pretty big application with really nasty code. The problem is that from time to time the whole GUI of the app is freezing and stops responding (and after some time Windows wants to take the app down). I have a really big problem to even look where to debug the app, mostly because when this thing happens and I pause it in the VS debugger, it highlight the line:
CardWindow.ShowDialog();
It's not helpfull at all. Also when this thing happens it tends to grow the app size in the memory, ocasionally throwing OutOfMemoryException.
I also checked whether it might be some kind of an infinite loop in one of created threads, but VS shows me that only the main thread is active, and the rest are either ended or not running at all (the thread implememtation is also really poorly written).
The application uses remote objects within local networks, and some threads are used to transfer photos and other data from clients to server, but I don't know how to check if this is what it's causing it. But when the server app hangs, the clients are still fully capable to connect with it.
Short info of how it's made: the app uses Firebird engine to store its data. The DB is on the server machine, and the clients are connected via local LAN to it using standard Firebird C# library, and the app instances communicates with each other using remote object (the server is also a client).
It's the second week of debugging and I'm getting pretty desperate as I'm getting out of ideas of even how to check what's wrong. The fact that the bug appears randomly also doesn't help.
Can anyone give me some ideas of how to find a trace of this bug?
Using C# .NET 4.5 and WPF with Visual Studio Ultimate 2013 and Firebird 2.5
I'd suggest using a profiling tool to assist in finding the problem
What Are Some Good .NET Profilers?
In addition to #DerekTomes. The System.Windows.ShowDialog method, Described in: Window.ShowDialog Method, all other windows are disabled and return only when the window is closed. Check to make sure the window is eventually closed(this.Close() in the CardWindow.xaml.cs or whatever .cs file) or use CardWindow.Show() instead of CardWindow.ShowDialog() so other windows remain running while the CardWindow is running.
I finally figured it out.
When the function that usually hanged the app after 30th run launched, I could see that some of it ran (the window's title changed as it was supposed to). I've found this function and after every single line put:
this.Title = "1";
SomeFunction();
this.Title = "2";
AnotherFunction();
this.Title = "3";
// and so on
I localized what was causing the problem; there was a function that changed the GUI significantly (lots of foo.Visibility and foo.Opacity) and ran in some weird loop. It was fine for the first 20 times to run it, but after 30th it slowed down the app, and after 40th - caused crash.
It now runs only once when it needs to and the problem does not appear. I suppose it caused GUI memory overflow of some kind.
Anyway, thank you for your answers - I ran memory profiling, but it slowed my app down to that point it was impossible to use it.
I've got a very bizarre situation. It appears that, when I load a webpage to my browser,
multiple threads (at least 2) are starting up. The app loads and runs fine on a
Windows XP box, but when I try to run it on my Windows 8 laptop it would seem that
more than one startup event is taking place and causing all kinds of collisions. This
is happening with both Firefox and IE.
To verify this behaviour, I placed a static int within a class, checked it to see if its
value is greater than zero, throw an exception if it is, then increment the int.
Of course, the exception is thrown.
What's very weird about this is that there is no multi-threading/multi-tasking involved
within my app.
When I "touch" the DLL for the webpage (rebuild it), it renders the webpage properly,
but the source for the webpage ("right click" > "View Page Source") has the source
for the unhandled exception webpage, with the message for the exception that my code
throws when the thread count is greater than zero.
I've tried creating a new project, then linking the code to it (Add Item ... Ad As Link),
then building it. It didn't do any good.
The Win XP system has IIS 6 with .NET 4.0, and the Win 8 laptop has IIS 7 with .NET 4.0.
Language is C#.
The truth is that I'm pretty much clueless about IIS.
I hope someone smarter than I am (which isn't saying much) has an idea as to what
is going on.
It appears that, when I load a webpage to my browser, multiple threads (at least 2) are starting up
Maybe onetime initializations. I doubt that every request causes an additional two threads to stay around.
it would seem that more than one startup event is taking place
That's normal This event fires for each instance of HttpApplication being created. This is basically a design error in ASP.NET. They thought that pooling HttpApplication instances and assigning one of them for each request was a good idea. It would have been better to have a singleton per AppDomain. Write this yourself. Like that:
class MyGlobalAppState { ... }
static Lazy<MyGlobalAppState> state = new Lazy<...>(StateFactory);
Be aware, that Lazy<T> stores any exception and just rethrows it. This causes your app to be permanently broken in case StateFactory throws. It will never recover without pool restart. This is a design error in Lazy<T>. Find a way to deal with that.
but the source for the webpage ("right click" > "View Page Source") has the source for the unhandled exception webpage
Some browsers re-GET the page to view the source. This can be annoying or handy.
It is hard to tell what is causing this behavior but as others suggested try to use Fiddler or any other http tracing tool to see what requests are sent.
Also, Win XP should be running IIS5.x while Win8 should be running IIS8.
By default IIS8 AppPool should be running with the integrated pipeline, which may behave differently. I would try changing the AppPool to use the Classic pipeline to see if it makes a difference.
I need to load a third party script file(which I do not have any control), but I want to avoid hanging the page in case the script has an infinite loop in it.
I tried calling the javascript file and put it in an updatepanel only on a click of a button but the page still hangs. I even tried putting it in an iframe just to separate it from other controls and the same scenario happens.
Is there really NO way to stop an infinite loop once it has started executing?
You are trying to add handling to a bug that is already fixed, so all that is going to happen is your code is going to become more complex unnecessarily.
I would have faith in the fix that they have produced, and you could look into adding Unit Tests that will allow you to test the bug in a secure manner
Edit
If you think the bug still exists then you could create a small test example (i.e your unit test) to send to the third party in hope of a better fix
Use debugger; to debug the script file. Put debugger; symbol beginning of the script's method which will be executed and run in chrome (since it is easy to debug) . click F12 to switch on the debugger tool. The script execution will stop on the line you put the debugger; and debug it line by line.
If the script is executing an infinite loop the chrome tab will crash with a message "Aw, Snap!". You can refer the call stack to find the method causing problem.
One possible solution could be is using Web Worker and run your JS code inside it. After a while, if there is no any responce from it, call worker.terminate() to "kill" it.
Pay attention that web workers has strong limitations: for example you can not access UI element from within the code that runs in web worker scope, and it's not supported on old browsers.
I don't know if web worker is suitable in your case, but this one is option that may help.
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.