[resolved] Minefield 3.0a1 crashes on startup - msvcr80.dll

polidobj · Post by **polidobj** » November 28th, 2006, 2:52 pm

Peter(6) wrote:If anyone by now knows the regressionwindow ... down to a few days is fine with me, please comment that in
#330271[Core:General]-crash when loading an https url (e.g. after trying to check for updates) [@msvcr80.dll] [Win]
I can most likely provide quite a few hourly builds that can narrow it down.
PM me if you need builds to test

My guess would be it happened when the compiler was changed. So it's probably not due to a bug fix. AFAIK the compiler change was when the problem popped up for Seamonkey, Thunderbird and Sunbird. And they changed at different times I believe.

Peter(6) · Post by **Peter(6)** » November 28th, 2006, 3:48 pm

polidobj wrote:
Peter(6) wrote:If anyone by now knows the regressionwindow ... down to a few days is fine with me, please comment that in
#330271[Core:General]-crash when loading an https url (e.g. after trying to check for updates) [@msvcr80.dll] [Win]
I can most likely provide quite a few hourly builds that can narrow it down.
PM me if you need builds to test
My guess would be it happened when the compiler was changed. So it's probably not due to a bug fix. AFAIK the compiler change was when the problem popped up for Seamonkey, Thunderbird and Sunbird. And they changed at different times I believe.

I should have read this thread better.
#330271[Core:General]-crash when loading an https url (e.g. after trying to check for updates) [@msvcr80.dll] [Win] was an early thing that doesn't seem to have much to to with the header of this topic.
That seems about a bug that started on 20060719.
Yet no one ever mentions a bug number for it.

ChefChaudart · Post by **ChefChaudart** » November 29th, 2006, 12:02 am

polidobj wrote:My guess would be it happened when the compiler was changed. So it's probably not due to a bug fix. AFAIK the compiler change was when the problem popped up for Seamonkey, Thunderbird and Sunbird. And they changed at different times I believe.

Exactly !

My Thunderbirds trunks came with same issue end of October ... So far, I cannot test Firefox builds since July, and TB trunks since October ...

polidobj · Post by **polidobj** » November 29th, 2006, 9:01 am

ChefChaudart wrote:
polidobj wrote:My guess would be it happened when the compiler was changed. So it's probably not due to a bug fix. AFAIK the compiler change was when the problem popped up for Seamonkey, Thunderbird and Sunbird. And they changed at different times I believe.
Exactly !

My Thunderbirds trunks came with same issue end of October ... So far, I cannot test Firefox builds since July, and TB trunks since October ...

But the flaw in that logic that I see now is that if I recall correctly Firefox changed compilers back in February when they switched to cairo. So the compiler is part of it. But you did at one point have a working Firefox built with VC8. Is that correct? Or were you using non-cairo builds?

polidobj · Post by **polidobj** » November 30th, 2006, 8:18 am

Ted found the problem. I confirmed it. I changed a file in the system32 directory to a really old date with the touch program. And Firefox crashed just after the window appeared in MSVCR80.dll. I changed the date again to a current value and no crash.

Ted Mielczarek wrote:So I have a strong suspicion that bug 330271 is a dupe of bug 331404. Can anyone who's experiencing this mysterious MSVCR80.DLL crash on auto-update or https URLs check out 331404 and attempt to verify this? There's an attachment on there ( https://bugzilla.mozilla.org/attachment ... ction=view ), a program named findold.exe. Running it will show you if there are any files in your windows/system32 folder with bad timestamps, which would cause CRT assertions in NSS.

That bug is fixed on NSS trunk, but not on the branch that Firefox trunk builds from. If it is indeed the source of these crashes, we might have some traction in getting that fix on the NSS branch we need.

Ted Mielczarek · Post by **Ted Mielczarek** » November 30th, 2006, 8:26 am

I'm not 100% convinced that it's the same bug, but it does look the same. Someone who is experiencing this crash needs to verify using findold.exe, and then try modifying the dates on any files it finds, and see if that eliminates the crash.

EDIT:
Ok, one verification is good enough for me. I've duped the bug. Now here's hoping we can get that fix onto the NSS branch that trunk FF uses.

DirtyRobotFeet · Post by **DirtyRobotFeet** » November 30th, 2006, 9:19 am

Thank you Ted!!

In my case it was wdh7231.ocx with create and write dates of 1618-06-21 19:26:42 UTC. Touching the file didn't change the creation date, so I used the free version of AttributeMagic to change it. Minefield doesn't crash now. Great job!

wgianopoulos · Post by **wgianopoulos** » November 30th, 2006, 9:59 am

So this is really a Microsoft bug I guess.

ChefChaudart · Post by **ChefChaudart** » November 30th, 2006, 10:04 am

Ted Mielczarek wrote:I'm not 100% convinced that it's the same bug, but it does look the same. Someone who is experiencing this crash needs to verify using findold.exe, and then try modifying the dates on any files it finds, and see if that eliminates the crash.

That's it !!!

I get a mswinsck.ocx with no attributes !

I downloaded a new one from http://www.ascentive.com/support/new/su ... WINSCK.OCX, and now, everything works !!! Even Thunderbirds !

Mick T · Post by **Mick T** » November 30th, 2006, 3:30 pm

yup, this fix worked for me also... Thanks guys !

RenegadeX · Post by **RenegadeX** » November 30th, 2006, 3:44 pm

Hooray! Thanks everyone - I used the findold.exe tool and found the following 4 files in my Windows\system32 folder that had no creation date (actually quite obvious when you do a sort by date, as their date fields are empty):

C:\WINDOWS\system32\ESG2D7GN.ocx has invalid Create time: 1617-06-20 23:34:38 UTC
C:\WINDOWS\system32\ILP6JVU6.ocx has invalid Create time: 1617-06-22 18:02:59 UTC
C:\WINDOWS\system32\LTDGHA8K.ocx has invalid Create time: 1617-06-19 05:06:17 UTC
C:\WINDOWS\system32\SK39DI0F.ocx has invalid Create time: 1617-06-17 10:37:57 UTC

Interestingly, all 4 of the above files are type:"ActiveX Control". I Googled each filename and all that came up were antivirus/file-type checking pages saying that its origin is unknown, possibly suspicious. I have a feeling that these were remnants of malicious browser-hijack or trojan-horse-installing ActiveX scripts.

ChefChaudart indicated mswinsck.ocx was the culprit for him - it should be a legitimate file, apparently - but a Google Search also shows that it has been a frequent target of trojans - as, I suspect were the .dll files that others have reported were on their system with no creation date. Running a malicious ActiveX script (in IE, no doubt) at some point in time would definitely explain why only some people's systems were affected. As it turns out, my 1 computer that was not affected is the one I do the least browsing on, and almost certainly the one that has had the least amount of IE time logged.

Anyhow, after identifying the 4 files, I made a new folder and moved them into it, tried Minefield 3.0a1 (which I'd downloaded & tested before moving the files) and yes, it works!

I am somewhat puzzled that user 'timeless' did not catch on to the fact that Bug 331404 which he was actively involved with in March and which pinpointed the reason for security-related msvcr80.dll crashes - was the same cause as the Bug he was actively involved with in August. In retrospect, it seems obvious.

In my own defence for not coming across it when I originally searched on Bugzilla, my Bugzilla search for 'msvcr80' does not even find Bug 331404 in its results. Can anyone explain why? (look at my link, and Edit search to see what parameters I used).

I'm also curious exactly what happened in the nsSafebrowsingApplications.js file on July 19th to trigger the startup crash - and also why accessing the Options dialog would also sometimes trigger the crash.

Anyhow, glad it's over - now I can finally test Minefield out. So far I'm not sure that it was even worth getting all excited about..

smellmypete · Post by **smellmypete** » November 30th, 2006, 9:05 pm

Fantastic! It's so great to be back to using the trunk builds after two and a half months.

Ted Mielczarek · Post by **Ted Mielczarek** » December 1st, 2006, 8:30 am

I'm just glad there was a workaround!

Old ssiter · Post by **Old ssiter** » December 1st, 2006, 8:59 am

RenegadeX wrote:In my own defence for not coming across it when I originally searched on Bugzilla, my Bugzilla search for 'msvcr80' does not even find Bug 331404 in its results. Can anyone explain why? (look at my link, and Edit search to see what parameters I used).

According to the Resolution field in your query you are only searching for open bugs and bugs that are resolved duplicate. But bug 331404 is resolved fixed.

RenegadeX · Post by **RenegadeX** » December 1st, 2006, 10:03 am

^ Ah, thanks. Yeah those were the default settings.
And it looks like the Bug was 'fixed' for NSS in July so with the default settings I would never have seen it when I did a default search in September. Makes sense.