2012-04-25 2 views
10

Я получаю исключение, заброшенное на DateTime.Now на нашем сервере работает несколько сайтов. Это произошло сейчас дважды для меня за последние 3 дня. Действительно странно. Мне интересно, это началось ли произойдет с последним обновлением Windows, и если какой-либо из вас видели подобное поведение приходя вDateTime.Now выбрасывает исключение

Исключение брошено является:.

BASE EXCEPTION: 
    TYPE: System.ArgumentOutOfRangeException 
    MESSAGE: Value to add was out of range. 
Parameter name: value 
    STACK TRACE: 
    at System.DateTime.Add(Double value, Int32 scale) 
    at System.TimeZoneInfo.TransitionTimeToDateTime(Int32 year, TransitionTime transitionTime) 
    at System.TimeZoneInfo.GetDaylightTime(Int32 year, AdjustmentRule rule) 
    at System.TimeZoneInfo.GetIsDaylightSavingsFromUtc(DateTime time, Int32 Year, TimeSpan utc, AdjustmentRule rule, Boolean& isAmbiguousLocalDst) 
    at System.TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc(DateTime time, Boolean& isAmbiguousLocalDst) 
    at System.DateTime.get_Now() 
    at (my code).FrontEnd.FrontEndPage.Page_Load(Object sender, EventArgs e) in (my code file)\code\presentation\FrontEndPage.cs:line 118 
    at (my code).purchase.Page_Load(Object sender, EventArgs e) in (my code file)\purchase.aspx.cs:line 94 
    at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) 
    at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) 
    at System.Web.UI.Control.OnLoad(EventArgs e) 
    at System.Web.UI.Control.LoadRecursive() 
    at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 

код, где это происходит, является первым строка в Условный оператор:

HttpCookie loggedIn = Request.Cookies[Config.Instance.LoggedInCookieName]; 
if (loggedIn != null) 
{ 
    loggedIn.Expires = DateTime.Now.AddHours(4); 
    Response.Cookies.Add(loggedIn); 
} 

Хотя есть AddHours там и исключение говорит о DateTime.Add, я не считаю, что это не имеет ничего общего с AddHours, но вызвано вызовите Now, как вы можете видеть в трассировке стека.

Сервер, на котором я работаю, работает под управлением Windows Server 2003 и работает на английском языке (Великобритания).

Спасибо за любую помощь.

+1

Звучит как изящное обновление Windows, вызвавшее его, или поврежденная установка .NET действительно ... – Noldorin

+0

Можете ли вы предоставить полную трассировку стека?Может быть, это как-то связано с этим? http://blog.brianhartsock.com/2009/02/21/systemargumentoutofrangeexception-at-systemwebhttpcachepolicyutcsetlastmodifieddatetime-utcdate/ – mellamokb

+0

Я знаю, что это может показаться маловероятным, но правильно ли установлено системное время? – hatchet

ответ

0

Это может быть вызвано DateTime.Now не является потокобезопасным (что, я считаю, будет ошибкой). Я слышал о некоторых версиях .net, имеющих эту ошибку. Это не обязательно поможет обернуть вашу строку кода в блокировку, потому что все вызовы DateTime.Now должны быть обработаны аналогичным образом. В качестве обходного пути я бы рекомендовал делать то, что сделал человек в подобном вопросе, - заманить исключение, созданное DateTime.Now и попробовать второй раз.

Можете ли вы написать небольшое тестовое приложение, которое вызывает DateTime.Now много раз на несколько потоков, чтобы заставить его и проверить, является ли это причиной?

Какая версия .Net используется этими сайтами?

+0

Все члены DateTime являются потокобезопасными. – porges

+0

@Porges - Это тоже мое понимание. Но он подходит для симптомов, особенно для другого аналогичного вопроса stackoverflow, где, если он не удалось выполнить один вызов, ему удалось немедленно вызвать DateTime.Now снова. – hatchet

+0

.NET Framework используется .NET Framework 4 –

1

Просмотрите код в Reflector, ваше исключение происходит, когда в строках AddDays указаны плохие данные в TransitionTimeToDateTime.

Оба вхождения AddDays процесса transitionTime.DayOfWeek, где transitionTime является rule.DaylightTransitionStart или rule.DaylightTransitionEnd от GetDaylightTime (а также time.DayOfWeek, но это всегда Mod 7).

Это означает, что GetTimeZoneInformation иногда возвращает плохие данные, где AdjustmentRule генерируется в GetOneYearLocalFromUtc, который вызывает GetCurrentOneYearLocal.

Поскольку это происходит редко, я не думаю, что это произойдет из-за коррумпированного реестра (я бы ожидал, что это произойдет каждый раз.), Но для дальнейшей проверки документации MSDN для TIME_ZONE_INFORMATION описаны записи в реестре Проверять.

Примечание эта информация не кэшируется и извлекается каждый раз, когда вы называете DateTime.Now, (который, конечно, правильная вещь, чтобы сделать, как DST мог бы просто изменить, или пользователь мог бы изменить текущий часовой пояс) а хорошим предлогом для некоторой преждевременной оптимизации, максимально используя DateTime.UtcNow и применяя .ToLocalTime только тогда, когда вам нужно отобразить время для пользователя.

Смежные вопросы