I have an asp.net web application that is hosted in Azure and using a Redis cache to manage session storage. Every so often, the application will hang when debugging in localhost for no apparent reason.
Essentially, in Visual Studio, I'll hit the start button. A new web browser window will open like it's about to open the page, but instead it will simply load and load forever. If I try pausing the debug session, it seems to always land somewhere within the Redis dll, but I can't be sure where exactly.
No matter how many times I kill all processes and restart Visual Studio, this behavior will continue until I restart my computer. What could possibly be causing this?
Redis was never designed to run on Windows, the version they make available is really only for testing purposes.
If you have issues with it hanging, it could be that it is miss-configured. This question on serverfault may help.
Related
Now that the use of one of my asp.net apps has gone up significantly, two odd problems are occurring that are very infrequent, and that I cannot reproduce.
I am at a loss as to how to debug and troubleshoot these problems.
Here are two examples:
One of my aspx pages resets a session state value to 0 on !IsPostBack (is true). However, one of my users at a specific location frequently comes to that page when it is not a postback and the session state value does not get reset on his laptop. (I am basing this statement on how the app subsequently behaves, not on running in debug mode) But the code works and the session state is reset on my laptop when I am sitting next to him running the app on my laptop using the same browser on the same internet connection at the same time. And when this user runs the app on his laptop from home where he has a better internet connection he does not have the problem as frequently.
One of the aspx pages in my app does a server.transfer to itself after running code that saves data to a DB. Almost all the time after the server.transfer the textboxes contain their default value (as they should since !isPostback==True), but about 1% of the time the textboxes contain the previous value. I know that there has been a roundtrip to the server because data has been saved. This problem occurs on the same pcs using the same browsers by the same users doing the same actions. So 99% of the time it works correctly, and 1% of the time they do the exact same thing and it does not work correctly.
How do I even start trying to figure out what is causing these problems if they seem to be occurring randomly?
I suspect that the quality of the internet connection is the issue because it is the one variable that is changing, but how does that info help me?
It's not like I can debug either of these problems by running my app in debug mode.
I am using Asp .Net 3.5, C# 3.5 and the app is run in IE 6-8. (IE 8 in compatibility mode)
I would add logging to code where the problem is occurring. Then inform the users who are having the problem to try and note the time when they run into the issue. Once you have the logs and an approximate time, you can go in and pour over these logs to see if anything points you in the right direction. I would also look at your IIS and Event Logs on the server.
You can install Firefox Throttle plugin to simulate slow connections. Lot's of things can happen in ASP.NET with slow page loads. If the page isn't loaded fully but items are clickable ASP.NET can get really upset with event validation...etc
Also, I encourage you to start logging and tracing the problem areas in your application. You can then correlate that with the IIS request logs and get a fairly accurate picture of whats's happening when.
It seems like you're having problems with Session State. By default, ASP.NET uses InProc session state mode which uses server memory to store values. In many occasions, this can be lost or reset (app pool recycled). Switching to SQLServer Session State might help you solve the issue.
I have created a message Queue here which is basically on a single thread and sending email one after another from the database. First I thought that since it is a continuous process, it has to be on windows service and it sounded like an ideal solution but not that I talked to my manager, he said that it would be better if it is in the same repository as the entire project and if I put in a while(true) statement. that way while deploying to the production, we do not need to worry about installing any windows service or anything. But what I think here is that if we do it that way then there would be a lot of unwanted pressure on the web server.
I am not sure which way to go. Any suggestions?
I would definitely suggest a windows service for processing the email queue in the background. Here are some points you can suggest to your manager:
The service could be kept in the same repository as another project.
Installing and upgrading services is very easy. Use installutil and add a batch file to your project for installing/uninstalling. Upgrading is a matter of stopping the service, updating the service .exe, and starting the service again.
All of this could technically be automated as well as part of your deployment process.
I'd go with a separate Windows service. With this service being party of your application, its life time is dependant on the life time of the application pool process (depending on the version of the IIS you are using, of course), and this way whenever youll choose to change the application pool settings, you will have to remember ur message job is also dependant on it, and if you set up any recycle settings for the app pool, you might have hard time uynderstanding why your job suddenly stop working or anything like that.
You can also go the route of simply writing a command line application and then wrapping it with something like Service+ to make it behave like a service. You also get other features like being able to run it like a command line application if you like (whenever you want to run it) or having it launch/execute from some other application as needed. You can build in a variety of behaviors as well... continuous mode, perhaps process 1 (or 100 or whatever) at a time then exit (and let Service+ restart it), or whatever else you may need.
I am developing a C# application (.Net 3.5, Win Forms) which is run on a server, and is accessed by Users using remote desktop. The application keeps freezing on seemingly random occasions on the remote machine (i.e. all GUI components turn to white, task manager reports the application to be not responding), but not when run locally (I'm not entirely sure about that, but failed to reproduce the freeze on my machine).
Has anyone experienced such behavior in his apps that are accessed remotely? What debugging strategy would you suggest? Do I need to consider something special when developing Win Forms applications that are accessed by remote desktop?
EDIT: some notes about the application and the freeze: The application does not recover from the freeze. Also, the freeze does not happen (or did not happen yet) during user interaction, but in between log ins to the remote machine. The application monitors a CFD solver, so it's doing things even when no one is using it.
UPDATE:
We did infact implement detailed logging, writing every function call to a file with a timestamp. Unfortunately, the results were not very conclusive. I.e. the last function call logged always returned correctly. Also, there were some background timers still running, even though the application appeared frozne (GUI completely white etc.). After some trouble we managed to have a look at a crashdump in WinDBG. On the system thread we found a call to OnUserPreferenceChanged() and further up to Invoke.WaitOne(). We can't say for sure yet, but it seems to be the issue decribed in these articles. As a quick fix, I installed a dummy handler to the event mentioned. I'll report how this works out.
UPDATE 2:
As it turns out, a Log In to a remote machine fires several OnUserPreferenceChanged() events. So it was indeed the suspected issue. The fix turned out to be not so easy though. I would have expected that an IllegalCrossReferenceException is thrown everytime a background thread tries to modify a control that was created on the system thread. This does not seem to be the case. I named my system thread and before each access to a control I asserted that the current thread name is the system thread's name. In various places this assertion failed (e.g. in a callback from a timer), but no exception was thrown. After using proper delegation at these places, the freezes stopped. The application runs nonstop for some weeks now and my users are happy again ;)
I do not think the freeze has anything to do with remote desktop. Adding logging was a good suggestion. I have a few suggestions, but without knowing the details of you application I can't get too specific.
The simplest suggestion I have is to check the memory useage and CPU usage in task manager when the freeze occurs.
If adding detailed logging is not an option, add just enough logging to know WHEN the application freezes. This could simply be a thread in the application which writes a timestamp to a file once a minute. Then you can see if there is any pattern in when it freezes, such as after a user has logged off, or when some of the data which you are monitoring changes, or at a certain time each day, or after being online for a certain amount of time.
A final and very hacky solution is to write a small watch dog application. This application's only job is to periodically check on the main application to make sure it is still responsive. How you dow this various drastically based on what your application does. If the watchdog sees the the main application has stopped, it can kill the thread for the main application and re-start it from the binaries.
if your using application streaming your server could be slowing the connection or waiting for packets that are dropping this can create this if your physical using windows remote desktop then there is your problem intense applications are not supposed to be run though remote desktop
AFAIK, there is no difference. Additionaly, I never experienced such a problem. I suggest, you try the following:
Extend your application with extended logging, to see what the users are doing when your application freezes
Check the network connection that is used to connect to the remote machine
Check the CPU usage during the freeze
If the freeze is for an extended amount of time, try to do the following:
Reproduce the freeze via remote desktop.
Go to the machine you just reproduced the freeze on and log in directly and see, whether the application is still freezed
If it is windows 10 version 1903 plus version. Then probably its the issue of windows. Please try the following settings:
Have read various blogs and concluded that the GPO has to force to use XDDM rather than WDDM. The issue is observed with windows 10 version 1903. Currently tested the workaround on machine NDT-61. It is working fine. Please practice the same for respective environment and let me know if some issue is faced.
Steps to Follow:
Open Group Policy Editor
Explore Administrative Templates
Explore Windows Components
Explore Remote Desktop Service
Click Remote Session Environment
Under Remote Session Environment Disable Use WDDM graphics display drive for Remote Desktop Connections
Note:
This policy setting lets you enable WDDM graphics display driver for Remote Desktop Connections.
If you enable or do not configure this policy setting, Remote Desktop Connections will use WDDM graphics display driver.
If you disable this policy setting, Remote Desktop Connections will NOT use WDDM graphics display driver. In this case, the Remote Desktop Connections will use XDDM graphics display driver.
For this change to take effect, you must restart Windows
Observation:
The policy settings are only available in windows 10 version 1903 and plus [ideally since when the issue started].
Hai All,
I'm developing the application using .net 2008 and Oracle 10g as database. I have deployed the application in IIS, now when two users get logged into the same applicaion, same page at a time getting error as
"*Connection must be open for this operation.Cannot access a disposed object.object name: 'Oracle.DataAccess.Client.OralceConnection'.Connection must be open for this operation"*
Plz give a solution to solve this multiuser issue..
Thanks in Advance!!!!
The easiest way to look into what's happening on IIS is to deploy a debug build, connect to the machine the server is on, and run the CLR debugger. Of course, this is only really practical in a staging rather than live scenario (or you have dozens or even thousands of people hitting the breakpoint, and of course the whole thing freezes up while you are stepping through).
This case sounds a bit like you might have a connection object statically scoped, or otherwise shared between threads, rather than created as needed on each thread of execution. It's the sort of thing sometimes seen if someone tries to manually pool connection objects (which is pointless, indeed counter-productive, as the underlying connector objects are pooled for you).
I am using C# to write a program that uses a web service from http://msrmaps.com, the problem is sometimes (seemingly at random) the site won't work properly and will return a few different exceptions. Then on subsequent attempts to use the service I get the error over and over, then after a while (sometimes 30 minutes) the service starts working properly again. In order to avoid waiting for the service to work properly again, I usually just close my program and start it back up again. Usually that fixes the problem and I can continue to use the web service.
My question: Is it possible to restart my program within the program or better yet is there a way to somehow re-connect to the web service like the program does when I first run it?
What is the program actually doing that depends on the web service? Does it really need to be re-started? It sounds like you should be able to just have some UI element in the application that attempts to connect to the service. Wrap that connection in some exception handling and somewhere in the application's UI display that the service connection is currently unavailable.
Or am I way off here?
Warning: This is a bit of a hack, but it works.
I'm assuming your application is unattended, so a UI change alerting the user to the need to shut down and restart is not an option.
We had a similar situation where the simplest resolution to a problem was to shut down and restart my app. (We'll call this "App A").
What I wound up doing was writing a second executable (We'll call it "App B") as a console app that did two things.
It used the System.Diagnostics.Process to kill any instance App A.
Use System.Diagnostics.Process to re-launch App A after all instances were killed.
Then in App A, I had a try/catch around the offending code, and when the error I was looking for came up, it would call App B.
This was the only way I could find of killing a program and relaunching it. If anyone has a better solution, PLEASE post it and I'll change my hack to use a better solution.
I would check that you don't have too many simultaneous requests happening at the same time due to each waiting for a long time before returning (and relatedly, that the total allowed connections as per machine.config is high enough). Throttling code can be very useful with unattended use of web-services (or any other remote service), if you've had a few failures in a row then wait a while before allowing another request to be made (I like to roll forward the wait period each time, starting a around a minute, maxing the wait at around 10minutes).
Then while you can't guarantee the other service won't go down, you can help prevent it causing a permanent problem, or reducing the performance of other processes.