Opening any .html file from any directory on my PC causes Chrome to create a "debug.log" file in that directory. I was probably just opening files from my Downloads directory when I filed the original report.

It only happens when double-clicking the file; opening the file from within Chrome doesn't repro the issue.

to scottmg@ as the only person who's touched this code in a while

Could GetModuleFileName() be returning an empty directory or the working directory, when Chrome is launched as a file handler?

I'm not sure if GetModuleFileName() can return empty, but we're not checking the return value, so maybe. Doesn't look great tbh since that could be uninitialized if that fails. It looks like we dump to the CWD on other platforms though.

As far as the actual content if the log, it looks like the crashpad database has been corrupted. I can't tell why from that, but it might be useful to save a copy of that if you could. (Not near a Windows computer, but I think it's %LOCALAPPDATA%\Google\Chrome\User Data\Crashpad or somewhere near there.)

And why there's actually a log file -- I don't think it specifically has anything to do with crash reporting, it's just where LOG()s get vectored to, and Crashpad is one of the few things that ships with LOGs enabled. Mark, how are you feeling about that decision? I feel like we're shipping a lot of logs, but not getting much out of them since they're still not uploaded.

It happens in Canary and my Beta install, so that would mean both databases would be corrupted?

I can send someone the zipped Crashpad directories if that would help. I'd just upload them but IDK what sensitive data they might contain.

I still do want to embed logged messages in crash reports. But at least in the Crashpad handler process, in the shipping configuration, I wouldn’t be opposed to defaulting to not producing a debug.log if messages are logged.

On the other hand, it sounds like we are detecting a bad situation here that may be impacting our ability to collect crash reports, and in that case I’d say “sorry for the spam, but I’m glad we caught this.”

Michael, I don’t think we need to see the entire Crashpad directory, just the “metadata” file from it should probably be enough. There isn’t anything sensitive in that file, it’s just an index of crash reports. You can send it to me and Scott directly, if you’d prefer. (We’d also take a .zip of the entire Crashpad directory.)

I've attached the metadata file for my main installation and Canary.

These are the files as of yesterday. As of today, the metadata file for Canary is actually empty (0 bytes), and the debug.log file is no longer created from the repro steps if Canary is my default browser.

Deleted: metadata SxS 244 bytes

metadata SxS 244 bytes View Download

The header in that file is

00000000  44 41 50 43 01 00 00 00  02 00 00 00 00 00 00 00  |DAPC............|

which, interpreted according to the struct

constexpr uint32_t kMetadataFileHeaderMagic = 'CPAD';
constexpr uint32_t kMetadataFileVersion = 1;
[…]
struct MetadataFileHeader {
  uint32_t magic;
  uint32_t version;
  uint32_t num_records;
  uint32_t padding;
};

seems fine to me.

Interestingly, a third-party program that apparently embeds Chromium exhibits the same behavior. This generated a debug.log file in the application's directory in C:\Program Files (x86), causing the directory and log file to persist after uninstalling that program. In this instance, the logs are:

[1221/142043.414:ERROR:crash_report_database_win.cc(427)] unexpected header
[1221/142114.201:ERROR:crash_report_database_win.cc(427)] unexpected header

(Note the line number is different, it's a different version of Chromium.)

BTW, the metadata file now consists of nothing but 212 null bytes.

+jperaza (new Crashpad database)
+mosescu (database ideas)