Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Debug Assertion Failed! msvcr80d.dll!__loctotime64_t Expression: (((long)(yr-1900) >= _BASE_YEAR) && ((long)(yr - 1900) <=

11 views
Skip to first unread message

Josh Soref

unread,
Mar 23, 2006, 1:20:40 AM3/23/06
to
It seems that windows file systems can have files dated to 1617, and
unfortunately if you call _findfirst/_findnext on such a directory,
msvcr80d will assert.

Is there some provision for changing msvcr80d so that this assert
doesn't happen?

Debug Assertion Failed!
File: dtoxtm64.c
Line: 67

Expression: (((long)(yr-1900) >= _BASE_YEAR) && ((long)(yr - 1900) <=
_MAX_YEAR64))

The top of the stack was:
msvcr80d.dll!__loctotime64_t(int yr=1617, int mo=11, int dy=3, int
hr=1, int mn=26, int sc=9, int dstflag=-1) Line 67 + 0x57 bytes C
msvcr80d.dll!__time64_t_from_ft(_FILETIME * pft=0x0012c52c) Line 253 +
0x25 bytes C
msvcr80d.dll!_findnext64i32(int hFile=1484232, _finddata64i32_t *
pfd=0x0012c684) Line 187 + 0xc bytes C

full details and stack can be found at:
https://bugzilla.mozilla.org/show_bug.cgi?id=331404

If there's some more appropriate group for this question, please let me
know. I searched around a bit, and this group seemed to be one of very
few candidates.

Jochen Kalmbach [MVP]

unread,
Mar 23, 2006, 2:12:32 AM3/23/06
to
Hi Josh!

> It seems that windows file systems can have files dated to 1617, and
> unfortunately if you call _findfirst/_findnext on such a directory,
> msvcr80d will assert.
>
> Is there some provision for changing msvcr80d so that this assert
> doesn't happen?

This is a limitation of the C-Standard not the CRT.
To handle date/times < 1900/1970 you must not use the C-Runtime.

YOu should use FindFirstFile/FindNextFile and FILETIME

> full details and stack can be found at:
> https://bugzilla.mozilla.org/show_bug.cgi?id=331404

And what should be the solution in the C-Runtime?

Greetings
Jochen

Ben Voigt

unread,
Mar 23, 2006, 9:58:08 AM3/23/06
to
"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message
news:e6BChkkT...@TK2MSFTNGP11.phx.gbl...

It should most certainly not assert. Assertions should only catch program
errors, not exceptional conditions in the environment.

>
> Greetings
> Jochen


Jochen Kalmbach [MVP]

unread,
Mar 23, 2006, 10:13:32 AM3/23/06
to
Hi Ben!

> It should most certainly not assert. Assertions should only catch program
> errors, not exceptional conditions in the environment.

asserts only happen in debug builds... and it is a good feature that it
asserts...

Greetings
Jochen

Jochen Kalmbach [MVP]

unread,
Dec 1, 2006, 5:53:15 AM12/1/06
to
Hi Ben!

>>> Is there some provision for changing msvcr80d so that this assert
>>> doesn't happen?
>> This is a limitation of the C-Standard not the CRT.
>> To handle date/times < 1900/1970 you must not use the C-Runtime.
>>
>> YOu should use FindFirstFile/FindNextFile and FILETIME
>>
>>> full details and stack can be found at:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=331404
>> And what should be the solution in the C-Runtime?
>
> It should most certainly not assert. Assertions should only catch program
> errors, not exceptional conditions in the environment.

As a small addition:

The release version of the CRT never asserts.
BUT: In the VC8 CRT MS improved and extended many validation of
arguments and values inside the CRT!
Then it will crash you app (execute an breakpoint-instruction) if it
encounters some "unhandled" situation.
See "_VALIDATE_RETURN" macro.

So the following code will crash your app with the following error message:
Microsoft Visual Studio C Runtime Library has detected a fatal error in
CPP.exe.

You can verify this with the following example:

#include <windows.h>
#include <tchar.h>
#include <io.h>

int _tmain()
{
HANDLE h = CreateFile(_T("\\old.file"), GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, 0, NULL);
SYSTEMTIME st;
ZeroMemory(&st, sizeof(st));
st.wDay = 1;
st.wMonth = 1;
st.wYear = 1602;
FILETIME ft;
SystemTimeToFileTime(&st, &ft);
SetFileTime(h, &ft, &ft, &ft);
CloseHandle(h);

_finddata32_t ff;
_findfirst32("\\old.file", &ff);
}


You can only prevent this by specifying and "invalid parameter handler":

#include <windows.h>
#include <tchar.h>
#include <io.h>

void myInvalidParameterHandler(const wchar_t* expression,
const wchar_t* function,
const wchar_t* file,
unsigned int line,
uintptr_t pReserved)
{
wprintf(L"Invalid parameter detected in function %s."
L" File: %s Line: %d\n", function, file, line);
wprintf(L"Expression: %s\n", expression);
}

int _tmain()
{
HANDLE h = CreateFile(_T("\\old.file"), GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, 0, NULL);
SYSTEMTIME st;
ZeroMemory(&st, sizeof(st));
st.wDay = 1;
st.wMonth = 1;
st.wYear = 1602;
FILETIME ft;
SystemTimeToFileTime(&st, &ft);
SetFileTime(h, &ft, &ft, &ft);
CloseHandle(h);

_set_invalid_parameter_handler(myInvalidParameterHandler);

_finddata32_t ff;
_findfirst32("\\old.file", &ff);
}


But this might trigger some followup-errors, because the datetime-field
of the "ff" structure will be "NULL"...

Also there are some error, which can't be catched...
See: "SetUnhandledExceptionFilter" and VC8
http://blog.kalmbachnet.de/?postid=75

Greetings
Jochen

0 new messages