964424 - Bandoo DLLs are corrupting the firefox.exe module information, breaking the load PATH as well as crash reporting

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Benjamin Smedberg]

We discovered in bug 962163 that when certain Bandoo DLLs are loaded (mgrldr.dll or safetyldr.dll) that the path to Firefox.exe is corrupted. This causes several unusual side effects:

1) the Firefox install path isn't actually on the Dll load path. This is what caused that particular crash with a delayload DLL.
2) The minidump system can't find firefox.exe, so the debug filename and debug ID are missing, which means that stackwalking fails.

I'm going to contact Bandoo about fixing this, or we should consider blocking Bandoo entirely. It has a history of causing crashes, being poorly engineered, and not being especially responsive.

Comment 1

[Benjamin Smedberg]

Got an email reply about this from Bandoo: NI?dmajor to check whether the new version has fixed things in crash-stats.

Comment 2

[(Away)]

This has been difficult to verify via the usual crash-stats reports, since the fix for bug 958108 and the Aurora merge came just before the Bandoo update.

Does your "crashes without firefox.exe" query (disregarding __delayLoadHelper2) show any improvement?

(By the way, the safetyldr and mgrldr DLL's don't carry version information, so I've just been looking at their timestamps)

Comment 3

[Benjamin Smedberg]

Making an automated report for that will be hard. I didn't realize that those DLLs didn't have version numbers. Maybe I can look by debug ID. Let's let this sit for a few weeks and I can see if it has dropped enough that we can just mark this WFM.

Comment 4

[Benjamin Smedberg]

Some supersearches say this appears to be fixed.