I created an asp.net application that asks users to add titles to a set of videos on a web page, and after it's submitted, begins writing manifest files and uploading the videos on a separate thread, using .net async. Most of the time it works well, however every once in a while I get the following exception:
System.Threading.ThreadAbortException: Thread was being aborted.
at System.Net.UnsafeNclNativeMethods.OSSOCK.send(IntPtr socketHandle, Byte* pinnedBuffer, Int32 len, SocketFlags socketFlags)
at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, SocketError& errorCode)
If anyone can let me know what this exception means, and what could be triggering it.
This is usually a timeout error.
Have you set a timeout or MaxLength for the file being uploaded? It could be exceeding the default values.
You can set them in your web.config
<system.web>
<httpRuntime executionTimeout="9999999" maxRequestLength="2048000" />
</system.web>
Is it possible that your background thread is trying to write to the network after the initial web page request has completed? If so, the net connection will be gone, and you'll get an Exception.
Related
I have a website which runs in IIS 7.0 in an Integrated v4.0 application pool.
Starting from today I get the below exception in the Windows event Log. The website is online for 1 month and I never got this exception before. I get the exception at the same minutes in every hour which is a little bit strange.
Some possible reason:
I have a library that I created that I load dynamically.
_searchProvider = (ISearchProvider)Activator.CreateInstance("SolrSearchProvider", "SearchProviders.SolrSearchProvider.SolrSearchProvider").Unwrap();
That library has reference to SolrNet.
Do you have any idea what the problem may be or how to investigate more into finding a solution ???
An unhandled exception occurred and the process was terminated.
Application ID: DefaultDomain
Process ID: 7192
Exception: System.Runtime.Serialization.SerializationException
Message: Unable to find assembly 'SolrNet, Version=0.4.0.1001, Culture=neutral, PublicKeyToken=bc21753e8aa334cb'.
StackTrace: at System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.AppDomain.Deserialize(Byte[] blob)
at System.AppDomain.UnmarshalObject(Byte[] blob)
I associated this failure with a heavy creation of new folders and of new image files inside one resource folder which is located in the same folder as the website.
I know that ASP.NET restarts the application pool in case of a folder deletion. Is it possible that something happened because of this new resources folder being created and somehow ASP.NET reloads assemblies ??
Mauricio Scheffer said: #Dorin: then the real problem is the circular dependency. I recommend posting a new question about that.
I solved the problem with circular dependency and I keep getting the same error in the Windows Event Logs.
First I get Unable to find assembly 'SolrNet, Version=0.4.0.1001, Culture=neutral, PublicKeyToken=bc21753e8aa334cb' and then the web applicatioin is restarting.
3 to 10 seconds before I get an exception in windows logs, I identified an expcetion in my site log files thrown by entity framework because I was trying to insert an item with the same primary key as an existing one. The exception was not treated in the code but was treated by asp.net because of the CustomErrors settings
<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
<error statusCode="404" redirect="/Error.aspx"/>
</customErrors>
Can this have anything to do with the error in windows log files ??
I found this statement on a blog post that besides the subject, also speaks about why an application pool might go down
"An unhandled exception in a thread not associated with a request will
take down the process. This occurs even if you have a handler setup
via the Application_Error method."
For some types of requests I create 8 new threads from the request threads to make simultaneous query to 8 different cores of my SOLR. In one of this cores I was getting an exception that I did not handled in that thread and that got me into the posted problem.
I hope that this helps somebody else if they encounter a similar error. Thanks a lot guys for the help. Because of your answers I improved my code and I discovered and fixed other errors not related to the question. Also I started to look more into how ASP.NET loads assembly which was for a great help.
where the assembly was installed? was in GAC or in bin folder?
has the hosting provider changed its settings?
try setting probing paths in config file , where CLR searches for dll.
Did you remember to add the assembly to the working directory of your application?
It has to be there in order for the serializer to find it and load the types.
Just copy it manually in explorer or write some method that copies the file to the working directory.
I am getting a ton of error alerts from one of my asp servers in a web farm, and all the servers have the same machine key in their web.config files.
I've looked around here but didn't find this exact case answered. Any suggestions would be welcome.
thanks for considering the question!
Here are some of the the error stacks (the query string is not from our app and could be part of something else):
Error message: This is an invalid
webresource request. Stack trace:
at
System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext
context) at
System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at
System.Web.HttpApplication.ExecuteStep(IExecutionStep
step, Boolean& completedSynchronously)
Source: System.Web Method: Void
System.Web.IHttpHandler.ProcessRequest(System.Web.HttpContext)
Page: QueryString: d=hAGTq1Iohid
These may have started when the Win 2003 server was patched. Later dot.net frameworks were installed on three other servers but not on the one throwing the errors.
Most of the error seem related to decryption but all servers in the same web farm now same machine key in their web config. But that has not stopped the errors.
Seeing as well :
"Length of the data to decrypt is invalid"
Error message: Length of the data to decrypt is invalid. Stack trace: at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount) at System.Security.Cryptography.CryptoStream.FlushFinalBlock() at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo) at System.Web.UI.Page.DecryptString(String s) at
System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
And Also
"Invalid length for a Base-64 char array"
Error message: Invalid length for a Base-64 char array.
Stack trace: at System.Convert.FromBase64CharArray(Char[] inArray, Int32 offset, Int32 length)
at System.Web.HttpServerUtility.UrlTokenDecode(String input)
at System.Web.UI.Page.DecryptString(String s)
at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Source: mscorlib
Method: Byte[] FromBase64CharArray(Char[], Int32, Int32)
And
"Invalid view state"
Error message: Invalid viewstate.
Stack trace: at System.Web.UI.Page.DecryptString(String s)
at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Source: System.Web
Method: System.String DecryptString(System.String)
Thanks again everyone.
I can't be sure, but it looks like a hack attempt trying to exploit the very serious .NET 'Padding Oracle' Crypto Attack, also discussed by Scott Guthrie. There is a patch available, so if you find that your server is indeed vulnerable, make sure you patch it immediately, and take damage-control steps if it has in fact been compromised.
This could also be caused by a problem with your application. However, if you're suddenly seeing large amounts of these errors, especially without any recent changes to your app, my first thought would be an intrusion attempt. The method used to exploit this vulnerability would generate errors related to decryption and bad data length.
If this server is the only one that is both unpatched AND showing the errors then the very first thing I would do is run all the windows updates on it.
Actually, let me make that statement less complicated: If this server is unpatched, start there and apply them.
UPDATE
You mentioned that the servers are throwing viewstate length errors. One thing we found was that several components, notably data grids, shove a tremendous amount of data into viewstate. Another thing was that several browsers would choke on this depending on length and not send all of it back.
After we made a particular web.config change this problem went completely away. Even Safari 3 started working right. Go to the <system.web> <pages /> node and make the following change:
<pages maxPageStateFieldLength="500" />
This will cause viewstate to be broken up across multiple hidden fields at 500 bytes each. It's an automatic split so none of your regular code has to change to support it.
You might play with the value, but essentialy some browsers can only send so much data back per input field. Depending on the version I've seen safari choke when those values were much more than around 700 bytes or so. Also firewalls and proxy servers might cause issues as well. See the following for a bit more information: http://weblogs.asp.net/lduveau/archive/2007/04/17/viewstate-chunking-in-asp-net-2-0-maxpagestatefieldlength.aspx
Another option to pursue is to have viewstate cached locally and not send it across the wire at all. Of course, that has implications in a web farm scenario so pick your poison.
Happened to me just now on a web site, for no apparent reason: The request for a web resource generated "invalid request" error and all the scripts were broken.
Could be an update to the server, maybe..
My solution was to go to the IIS control panel and to generate a new machine key for the site.
This seems to solve the problem, whatever that was.
I have several websites which get approximately 3000 pageviews in total per day, and I get this viewstate error roughly 5-10 times per day, caught in global.asax:
System.Web.HttpException: Unable to validate data. at System.Web.Configuration.MachineKeySection.GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength) at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
I have tried:
hard-coding the machine key in web.config for all websites
hard-coding the machien key in machine.config
adding items to the pages section of the web.config for all websites.
Machine key looks like:
<machineKey validationKey="key goes here" decryptionKey="key goes here" validation="SHA1" decryption="AES" />
Pages section looks like:
<pages renderAllHiddenFieldsAtTopOfForm="true" validateRequest="false" enableEventValidation="false" viewStateEncryptionMode="Never">
The errors are not related to application pool recycling as best I can tell, as the pool is set to recycle at every 100,000 requests. I am not running a web farm or web garden. Quite often I get two or three of these errors in a row, as if a user is getting an error, going back, and then clicking the link again.
Anyone have any ideas?
I have seen "random" ViewState errors before caused by slow internet connections. The slow connections would cause the page to be visibly rendered to the user, however it hadn't completely loaded. The user would then take action on the form and thus "random" issues would occur.
See if you can correlate the exception timestamps to specific pages being requested in the IIS logs. You could then try to re-create the low bandwidth scenario with something like Firefox Throttle.
Similar question below confirms my experiences and probably what your are seeing as well:
ASP.NET: Unable to validate data
I am fairly new to ASP.NET. I recently set up automated email from my website to notify me of an unhandled exceptions. Just a few hours ago in 3 minutes there were 10 unhandled exceptions and all stack traces were similar. There is a lot in the error messages I do not understand, but I do not like the way this looks.
Here is one of the email messages:
An unhandled exception occurred:
Message: Padding is invalid and cannot be removed.
Stack Trace:
at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Is this an attempt to hack into my site or something else?
Many thanks go to those who provided Answers and Comments provided which pointed me in the right direction to get an answer to this exception. It's cause can be difficult to determine, especially when not occuring in a web farm.
IE 5.5 was not causing the problem as I had earlier thought.
It was not easily found, but a post on my web host forum by one of the staff mentioned reports of Viewstate errors. The cause was attributed to the asp worker process or the server recycling.
The asp worker process settings refers to the processModel Element in the machine.config file. See http://msdn.microsoft.com/en-us/library/7w2sway1(VS.80).aspx for more information.
The recommended fix was to set an encrypted machineKey in the web.config file. The Machine Key node is in the system.web element.
This was easily done and solved the problem thanks to the handy ASP.NETResources site which has a MachineKey Generator. See http://www.aspnetresources.com/tools/keycreator.aspx.
This exception is thrown when the assembly resource handler gets an invalid request. It is unlikely this is related to any malicious activity; it's usually caused by an incorrectly configured machine config on the server.
Some background:
ASP.NET has built-in mechanisms for exposing resources from the assembly (dll) via an HttpHandler. Resources such as JavaScripts and images can be stored as text in the assembly and requested by the browser via .axd handlers. But for security reasons, the handlers don't accept a plain-text location of the resource, which might expose clues about how your code works. Instead, it uses information in the machine.config on the server to encrypt a unique identifier to the resource. This exception gets thrown when a resource is requested, but when the server tries to decrypt the identifier provided, it fails.
The error is because your appdomain was recycled/restarted. When that happens the application and the machine key is set to auto, it changes. That affects the decryption of the info in the url of the resources urls (.axd). Setting up a fixed machine key will prevent it from ever happening again.
Please check this for more info on a similar case (the explanation is with an issue with viewstate validation, but the cause is the same one):
http://www.developmentnow.com/blog/InvalidViewstate+Or+Unable+To+Validate+Data+Error.aspx
Ps. this explains it on single server deployments :) - although the solution is the same for both multi-single server, the fix was usually only explained to make all servers use the same machine key.
Update 1: The padding is invalid message doesn't have relation to the css padding. If it is only happening on ie 5.5, it is likely the parameters for the webresource.axd are being messed up, just like in this question: Invalid Webresource.axd parameters being generated.
I have an ASP.NET 2.0 application that is working fine in our local environment. When published to a test server, we're getting intermittent errors on the server.
Here's the most common:
Padding is invalid and cannot be removed.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details:
System.Security.Cryptography.CryptographicException:
Padding is invalid and cannot be
removed.
Source Error:
An unhandled exception was generated
during the execution of the current
web request. Information regarding the
origin and location of the exception
can be identified using the exception
stack trace below.
Stack Trace:
[CryptographicException: Padding is
invalid and cannot be removed.]
System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[]
inputBuffer, Int32 inputOffset, Int32
inputCount, Byte[]& outputBuffer,
Int32 outputOffset, PaddingMode
paddingMode, Boolean fLast) +1545747
System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[]
inputBuffer, Int32 inputOffset, Int32
inputCount) +257
System.Security.Cryptography.CryptoStream.FlushFinalBlock()
+30 System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean
fEncrypt, Byte[] buf, Byte[] modifier,
Int32 start, Int32 length, Boolean
useValidationSymAlgo) +164
System.Web.UI.Page.DecryptString(String
s) +83
System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext
context) +148
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
+358 System.Web.HttpApplication.ExecuteStep(IExecutionStep
step, Boolean& completedSynchronously)
+64
This happens on a request to a specific WebResource.axd request.
The other error that we're seeing is this:
Validation of viewstate MAC failed.
If this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster. Description: An
unhandled exception occurred during
the execution of the current web
request. Please review the stack trace
for more information about the error
and where it originated in the code.
Exception Details:
System.Web.HttpException: Validation
of viewstate MAC failed. If this
application is hosted by a Web Farm or
cluster, ensure that
configuration specifies the same
validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.
This error happens occasionally while posting a form.
Now before you jump in and tell me the obvious (usual) answer to this error, consider this:
The application is deployed to Windows Server 2003 on IIS6
It is NOT on a web farm. Only one webserver is in use here.
The application pool identity is a custom service account, and I did run aspnet_regiss -ga <username> on the server. No effect.
The error is because your appdomain was recycled/restarted. When that happens the application and the machine key is set to auto, it changes. That affects the decryption of the info in the url of the resources urls (.axd). Setting up a fixed machine key will prevent it from ever happening again.
Please check this for more info on a similar case (the explanation is with an issue with viewstate validation, but the cause is the same one): http://www.developmentnow.com/blog/InvalidViewstate+Or+Unable+To+Validate+Data+Error.aspx
I also had been wondering about it for quite a while. After I saw this question it got me on it again: Is this an attempt to break my ASP.Net site's security? ... which I just answered with very much the same. I had the feeling it was around some restart of something, because when we published something that recycled the application the error showed in the log, but I didn't have any other source stating its relation (today I found that case on invalidviewstate because of the machinekey change :))
Ps. above finally explains it on single server :)
This problem appears when a post is generated before the page is fully loaded in the browser. Have a look at this question.
Ben,
For your first problem, I found this that seems to be a bit more to the point of what you are seeing in that the problem is sporadically occurring.
You should be able to find a full explanation of this at http://www.codeproject.com/KB/security/Cryptor.aspx#aes.
What you really need to do is set RijndaelAlg.Padding to PaddingMode.ISO10126, PaddingMode.PKCS7, or PaddingMode.ANSIX923. Any one of these 3 values should work, provided that you use the same value when encrypting and decrypting. Other values will work with some data, but not with all data. The above URL explains why.
What I don't understand is the reason Microsoft provides options that sometimes don't work, or at least why they don't default to a reliable option.