System.ArgumentOutOfRangeException at System.Web.HttpCachePolicy.UtcSetLastModified (DateTime utcDate)
by bhartsock on Feb.21, 2009, under Uncategorized
I spent most of yesterday configuring a server, then delving into the aforementioned error with a few other devs. Here is basically what we did to figure it out, and what the cause was.
The error
The day started by setting up a new server, and getting our ASP.NET application up and running. At first, the error wasn’t apparent. It was when we started seeing javascript errors on different pages. It looked as though one javascript includes was causing the error, /WebResource.axd?d=KadOK03KouGAGUGwjTWw4w2&t=633707613869062500.
When pulling up the included javascript file directly in the browser, the full error was seen.
Type : System.ArgumentOutOfRangeException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Message : Specified argument was out of the range of valid values.
Parameter name: utcDate
Source : System.Web
Help link :
ActualValue :
ParamName : utcDate
Data : System.Collections.ListDictionaryInternal
TargetSite : Void UtcSetLastModified(System.DateTime)
Stack Trace : at System.Web.HttpCachePolicy.UtcSetLastModified(DateTime utcDate)
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)The problem
Google quickly helped me figured out what was causing it, some assemblies were dated in the future.
I was a little confused as to why though. I looked at the timestamp portion of the request, to see what its value was, /WebResource.axd?d=KadOK03KouGAGUGwjTWw4w2&t=633707613869062500.
PS C:\> new-object DateTime 633707613869062500 Friday, February 20, 2009 9:16:26 PM PS C:\> [DateTime]::Now Friday, February 20, 2009 1:21:22 PM
So the assembly trying to be loaded is ~8 hours in the future, not good.
Who is causing the problem?
Now I know what the problem is, but looking through all the DLL’s for timestamp problems could take forever. Powershell to the rescue.
gci -recurse | where { $_.LastWriteTime -gt [DateTime]::Now }
I ran this on the application directory, then C:\Windows\Microsoft.NET, then C:\Windows\assemblies.
Bam. The problem was in C:\Windows\Microsoft.NET and C:\Windows\assemblies.
(Side note: Smarty pants Lamar showed this could be done with just Windows search and ordering by the date column.)
My first idea
Can I change the LastWriteTime of a file?
PS C:\> gi c:\ | get-member LastWriteTime TypeName: System.IO.DirectoryInfo Name MemberType Definition ---- ---------- ---------- LastWriteTime Property System.DateTime LastWriteTime {get;set;}
Yes, there is a setter!
gci -recurse | where { $_.LastWriteTime -gt [DateTime]::Now } | %{ $_.LastWriteTime = [DateTime]::Now }
Well, that worked for C:\Windows\Microsoft.NET, but not C:\Windows\assemblies since all the DLLs in there are in use.
The final solution
Reinstall .NET framework, entirely. I know, you were expecting something amazing, and I failed you. Well, sorry. I was annoyed too, but it was the easiest way I could think accomplish the task. What is important is how I was able to use Powershell to test out different scenarios and possible solutions. If I would have had to write a command line program in Visual Studio to figure out what different timestamp values actually were, I wouldn’t have done it.
The other question you might have is why were times so off? Well, the server was a fresh install and the time wasn’t set properly for some reason. .NET was installed before checking the time that was set. This would have been fine, but the server was added to the AD domain, which quickly changed the time to the correct time.
8 Comments for this entry
1 Trackback or Pingback for this entry
-
WebResource.axd引起的问题以及asp.net程序集与服务器时间的问题 by 找对象_51obj.cn
March 14th, 2010 on 10:54 am[...] 关于这个程序集与服务器时间问题的更详细内容，可参考此文http://blog.brianhartsock.com/2009/02/21/systemargumentoutofrangeexception-at-systemwebhttpcachepoli… [...]
February 26th, 2009 on 4:52 am
Hi,
I’ve had the same issue. Some of my testers have been testing batch jobs using historical data. To trick our scheduler app they have changed the system date to a date before the framework was installed.
You do not need to re-install the framework. You simply need to change the file created and modified date on the System.Web dll in the gac. File location (on win server 2003) should be C:\windows\assembly\gac_32\system.web\2.0..(can’t remember)..\system.web.dll
I wrote a little app to do this as i’m not too familiar with command line tools. You will need to remove the readonly file property beforehand.
Hope this helps someone
)
June 23rd, 2009 on 11:44 am
Hi, having the same problem, but the time difference is caused because we’re building (and precompiling) our site on a machine in London (currently in UTC+1) and copying those files onto a server in a US time zone (UTC-5). Never thought this could cause a problem…
July 27th, 2009 on 10:42 pm
I was having the same issue. I built my web project in Australia (UTC+10) and copying those files onto a server in UK. In the end, I didn’t reinstall .NET framework. My solution was to simply changed the date time on that machine and run the web site again.
November 25th, 2009 on 2:05 am
This is why all servers should run in UTC
November 25th, 2009 on 9:43 am
I agree 100%
February 10th, 2010 on 10:52 am
Having exactly the same issue, but can’t find any future dated files, let alone assemblies on the server. Does anyone have any other ideas?
March 14th, 2010 on 9:45 am
You enter these letters:
PS C:\> new-object DateTime 633707613869062500
what’s this?
March 14th, 2010 on 9:53 am
After I search it in google,I see.that’s PowerShell command.thanks!