I have had a user of my VB.net web app complain he keeps getting an intermittent error message, causing him to crash out of the system.
Stack Trace:
[FormatException: Invalid character in a Base-64 string.]
System.Convert.FromBase64String(Strings) +0
System.web. UI. LosFormatter.Deserialize(String input) +25
System.web. UI. Page. LoadPageStateFromPersistenceMedium() +101
[HttpException (0x80004005) : Invalid_Viewstate
Client IP: 127.0.0. 1
Port: 3491
User-Agent: Mozilla/4.0 (compatible: MSIE 7.0; windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET
ViewState: dDwxMZUZMDI3MTC203Q802w8aTwxPjS+02w8dDw7bDxpPDU+02 kBNj47aTw4PjtpPDEDPjtpPDE4PjtpPDIwPjtpPDIXPjtpPDM OPjtpPDM1PjtpPDM2PjtpI
Http-Referer: http ://localhost/<appname>/webForms/frmSystem.aspx?User=2&systemNo=22011U&Zoom=1&Strips=6
Path: /<appname>/webForms/frmSystem.aspx.]
System.web. UI. Page. LoadPageStateFromPersistenceMedium() +442
System.web. UI. Page. LoadPageViewState() +18
System.web. UI. Page. ProcessRequestMain() +447
It appears from the error message that the viewstate keeps becoming corrupt (see screen-dump below), but I don't understand why. He claims it happens every 2-3 minutes, but I've used the system a lot and have never experienced it.
I should mention too that he is using the web-app in a very "non-standard" way. To achieve optimum speed he's actually using remote desktop, to connect to our server directly, and running it as localhost. ("Madness!"- yes, I know. I didn't make the decision.) That may not be relevant of course.
Some advice on what is likely to be causing the viewstate to become corrupt would be extremely helpful.
Screen-dump of error
He is double clicking. Same thing drove me nuts for a long time because I know how many times to click on things and never saw the error myself.
Related
We upgraded our asp.net core 3.1 web app to version 5. It's hosted in IIS. All servers are fine. We go to production and we can't stay stable because of the following error at the bottom. Just flurry of errors so we had to roll back until we can resolve this issue.
Looking at the breaking changes from 3.1 to 5 - I'm still not spotting anything. Looking at the Microsoft source code I'm still not sure how the error would come about. Any help would be appreciated.
An unhandled exception was thrown by the application.
System.ArgumentOutOfRangeException: Version doesn't map to a known HTTP protocol. (Parameter 'version')
at Microsoft.AspNetCore.Http.HttpProtocol.GetHttpProtocol(Version version)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.Microsoft.AspNetCore.Http.Features.IHttpRequestFeature.get_Protocol()
at Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware.IsEmptyHostAllowed(HttpContext context)
at Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()
Mono 3.2 MVC4 WebAPI application is running in Debian x64 VPS server. Mono is compiled from source and 4.5 subtree is used.
Application requires Chrome or Safari browser.
After refreshing browser window several times server does not work properly. I tried all known free possibilites:
Apache + mod_mono
After pressing browser refresh button several times server randomly returns 500 error for some pages
and apache error log contains "failed to map path" exception.
I posted it in
https://stackoverflow.com/questions/20356779/how-to-fix-failed-to-map-path-errors-in-mono-mvc4-application
and in
Mono ASP.NET mailing list without any response.
There are number of mono applications in server, maybe mod_mono selects wrong thread or is there some bug in webapi mapping implementation in mono.
Nginx + mono-fastcgi-server4.exe
Holding down F5 key causes 200% CPU usage forever in mono-fastcgi-server4.exe
I posted it in
https://stackoverflow.com/questions/20512978/how-to-limit-mono-197-cpu-usage-in-mono-fastcgi-server
and in
Mono ASP.NET mailing list without any solution.
Is looks like there is bug in mono fastcgi server or it is not compatible with mono 3.2
Using xsp4.exe directly
It causes "server does not return data" in Chrome if browser window is refreshed several times.
I posted this in
https://code.google.com/p/chromium/issues/detail?id=329311
without response.
Maybe xsp4 does not implement http protocol properly.
Havent tried ServiceStack since it cannot used for closed source development which is required. Also application uses also images, css, js files and MVC views which needs also served.
How to create proper server for mono which returns correct data ?
When 500 errors happen, somewhere in the mono class libraries an exception was thrown, you can find out more by using tracing:
mono --trace=E:System.Exception YourApp.exe
This way it's very possible that you find out what is causing the load problems you're seeing in each case (to do this for mono-fastcgi, you would need to add the trace argument in the script that calls mono-fastcgi-server4.exe).
Some websites, especially the ones that are fancy with HTML 5 and whatnot, will verify the browser that you are using, and give you a little warning message like: "Warning you are using an untested browser" if your web browser isn't in their little white-list.
Sadly these websites do not recognize IE controls as being Internet Explorer Browsers, so sometimes they show unnecessary warnings/errors
Is there any feasible way for me to make my webbrowser control show up as Internet Explorer 9 instead of whatever it actually shows up for, that way if the website has already tested Internet Explorer 9 for functionality, it will not show any errors.
Thank you!
By default WebBrowser control is detected as IE7, to see this - try to navigate to "What is My User Agent":
WebBrowser1.Navigate("http://www.whatsmyuseragent.com/")
Easiest way to change this is to pass user agent of a different browser as the last parameter of "Navigate" method. Open http://www.whatsmyuseragent.com/ in your normal IE9, copy the displayed string and use it as parameter e.g.:
WebBrowser1.Navigate("http://www.whatsmyuseragent.com/", Nothing, Nothing, "User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)")
The problem you're hitting is that, by-default, IE Web Browser controls run in legacy Compatibility modes. To resolve that, set Feature_Browser_Emulation for your process (ensure you write to both the 32bit and 64bit registry keys if your project is compiled for AnyCPU. See webbrowser using ie10 c# winform for more details.
If you wanted to send a different user-agent string (which is such sites determine what browser version you're using) you need to use the URLMon API UrlMkSetSessionOption as discussed here: http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx
After registering(RegAsm) my C# COM visible class, I see that CoCreateInstance(__uuidof(myclass)) takes a lot of time only for the first time, subsequent attempts in the same client process are resolved instantly. Any idea why is it taking time?
NGen is not an option for me.
My COM Server is in C# and client is in MFC/ATL
CComPtr<namespace::Imyclass> obj;
hrx = obj.CoCreateInstance(__uuidof(namespace::myclass));
The first call to CoCreateInstance has to load into the process, and initialize, the .NET runtime. Then, your DLL has to be loaded, "verified", and compiled into machine code (although just-in-time helps a lot to speed-up the startup). The .NET runtime also has to parse the metadata of your assembly, and then dynamically generate and compile the "COM callable wrappers" (http://msdn.microsoft.com/en-us/library/f07c8z1c.aspx) which are the proxies that bridge between the unmanaged COM world and the managed .NET runtime. Any additional libraries your code might use also needs to be loaded, verified and possibly compiled into machine code (if not NGEN'd).
This is inherently an expensive process. The delays you mention are not unheard of.
I don't believe there is much you can do to speed things up. I suggest you think about whether you can take the hit early in your program's lifetime by creating an object soon after startup. It won't make it faster, but it might improve the user experience dramatically. if your program just can't tolerate the delays, then you should not use .NET to write the COM object (more specifically, you should not use .NET in your process at all. This is not an issue with using COM; it's an issue with loading .NET)
Incidentally, this is one of the reasons why writing shell extensions in .NET is... "highly discouraged". See this recent post on this subject, which touches on the startup performance of .NET as well: http://blogs.msdn.com/b/oldnewthing/archive/2013/02/22/10396079.aspx
(That's why I asked earlier what kind of client you were running. A client that already runs .NET managed code depends on the .NET runtime and would not be affected by these delays)
The first call to CoCreateInstance is likely having to consult the registry and the file system, loading the appropriate code, allowing it to initialize, and finally invoke a factory to create the instance you've asked for (if it could be located).
The second call benefits hugely from these previous steps. If the first call was successful, then the code is already loaded and initialized, and all it has to do is invoke a factory a second time.
If this delay is only for first load (after computer start), then this is caused by loading all libraries. First delay after start (or after long time without usage of .NET) will always be slow. (See Micelli answer)
Delay can be also caused on each loading. Today I found out that internet connection can also cause the delay.
Measured values:
No Ethernet and no WiFi connection delay: 94 ms (Win7) / 1.5 (WinXP)
Windows XP: Internet connection (with proxy and non standard gateway; not all ports are allowed): 4-5 s (WinXP)
Connected to Ethernet not not to Internet: 10 s (Win7)
Short after the connection to Ethernet (Windows test Internet connection; blue circle on the Network Icon): 30 s (Win7)
Internet connection (with proxy and non standard gateway; only few ports are allowed): 30 s (Win7)
*non standard gateway: allowed TCP ports and connections are different for each computer (Different for WinXP and Win7).
Tested on Windows 7 (x64) and WinXP. I tested it because it came as a complain from a customer and located the delay to CoCreateInstance The loaded library is in c# and is signed (signed assembly with snk and with standard certificate for signing executable files).
See also: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/cda45e39-ed11-4a17-a922-e47aa2e7b325/ce-40-delay-when-cocreateinstance-on-pc-without-internet?forum=sqlce
I have created a simple JSF image browsing app, and I'm having a problem with firefox.
The app itself is running inside Tomcat. The pictures are stored in a directory that is served by Apache. I've got 9 pictures that get shown on a page. The servers are on a machine separate from the client. When I try to load the page in firefox, usually 6 of the pictures will load almost instantly (< 500ms). The other three will take between 15 and 20 seconds to load. Looking at the apache logs, it seems like firefox isn't requesting those three pictures until the 15-20 seconds have passed - that is, I see 6 requests at the same time, then 15 seconds later the other three. I have tried the site in internet explorer, and IE doesn't have this problem; it loads all 9 pictures right away. I've tried a few different machines, and have the same results. The html is rendered very quickly, < 200ms, so I don't think this is a JSF issue (especially since the pictures are served from apache).
The numbers aren't always the same either - sometimes it will load 8 images, sometimes 7, sometimes the second batch of requests will all come at once, and sometimes it will load 2 more, than one more, etc. I'm not sure if this is a firefox setting, or a bug, or if there's anything server side I can do about it, but I thought that I'd throw it out there and see if anyone has any ideas I can try.
If it helps, here's an apache log line from firefox
192.168.1.30 - - [04/Mar/2009:14:25:40 -0500] "GET /work/DSCF0185_thumbnail.jpg HTTP/1.1" 200 7902 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)"
and one from IE
192.168.1.30 - - [04/Mar/2009:14:34:14 -0500] "GET /work/DSCF0179_thumbnail.jpg HTTP/1.1" 304 - "http://192.168.1.83:8080/app/browse.jsf" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 1.1.4322; MS-RTC LM 8; Windows-Media-Player/10.00.00.3990; FDM; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
Edit
I got the timings from Firebug - it's showing that the entire request is (for example) 18 seconds, with 17.9 seconds "recieving data", and the rest taken up in queuing. I'm not seeing the actual request in the Apache log until the end of that 17.9 seconds though, which leads me to believe it's a firefox thing, especially since IE doesn't show the problem. If it were in the server, I would expect to see the problem in both browsers.
Pipelining in firefox is turned off.
As was pointed out, my IE log shows it's hitting the cache - my mistake, grabbed the wrong part of the log file. Here's a clean log line - even after a cleared cache, IE doesn't show the same problems as firefox.
192.168.1.30 - - [04/Mar/2009:15:52:18 -0500] "GET /vantagework/DSCF0189_thumbnail.jpg HTTP/1.1" 200 5805 "http://192.168.1.83:8080/vantage/browse.jsf" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 1.1.4322; MS-RTC LM 8; Windows-Media-Player/10.00.00.3990; FDM; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
Use Firebug's "Net" console to check whether it is firefox, or the webserver, as your webserver might be taking it's time to accept the connections.
Firebug's "Net" console will show you when it starts requesting things, and give you a detailed breakdown of the different parts of requesting the image (queuing, etc etc)-
According to your log snippets, IE is retrieving the image from cache, Firefox is getting it from the server. So if there is something wrong with the server configuration that is delivering the image slowly, you will only see similar behaviour in IE if you clear the cache first, so I'd try that to verify that non-cached images do indeed take different amounts of time to download between Firefox and IE.
The other thing I would check is to see whether you have pipelining enabled in Firefox. If you do, I'd suggest you disable it, it maybe be causing a problem for your server.
It turns out that this was caused by my apache configuration. Some tuning adjustments had been made, and reverting to the out of the box apache configuration fixed the problem.