Thanks for raising the issue Bruce but this dll doesn't contain any code (built with the /NOENTRY flag). It only contains a string table for the Windows Event Viewer to use when showing entries generated by chrome with the SYSLOG macro.
I don't know if VC even generates a PDB for that file, but I guess it doesn't. 

Thanks for the information.

The DLL doesn't *quite* have no code. It has three bytes of code. I'm not sure if we can/should try to tweak the build to avoid generating that - it's not worth most effort to save the ~500 bytes of disk space that it uses.

I checked and our build does create a PDB - all 102,400 bytes of it. It may be that the best thing to do is to ship this PDB just for consistency, to prevent future developers from wondering where the symbols are, and in order to record (through the source indexing) what version of the source code was used to build the DLL. But, these are not super compelling reasons so I could go either way.

I will try to get the pdb in the archive. I had enough fun with the FILES.cfg file lately so some more won't harm. :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7e68269619bfa96b659d0b34310ad77aea857ce0

commit 7e68269619bfa96b659d0b34310ad77aea857ce0
Author: pastarmovj <pastarmovj@chromium.org>
Date: Tue Jan 10 08:46:46 2017

Add eventlog_provider.dll.pdb to the archive of symbol files.

Although eventlog_provider.dll is resource only dll archiving the
pdb file together with the rest of Chrome will allow for better
tracing of the version of the source code used to build the dll
shall this ever be needed for issue investigations.

BUG= 677226 
TEST=Builds fine on all builders.

Review-Url: https://codereview.chromium.org/2616373002
Cr-Commit-Position: refs/heads/master@{#442534}

[modify] https://crrev.com/7e68269619bfa96b659d0b34310ad77aea857ce0/chrome/tools/build/win/FILES.cfg

It doesn't seem to be showing up. As of today's canary (built January 12th) it is the only PDB that doesn't download. I'm not sure why it wouldn't, or how much we should care...

Hmm, Greg, do you know if anything else has to be done to make this happen?

Maybe there is some other list of which PDBs get uploaded to the symbol server and it is not the whole zip file mentioned in the FILES.cfg file?

I see log entries for the symbol upload step indicating that /something/ is happening with them:

[21:38:31] Uploading C:\b\build\slave\win64\build\src\out\Release_x64\eventlog_provider.dll
src\breakpad\symupload.exe --timeout 0 C:\b\build\slave\win64\build\src\out\Release_x64\eventlog_provider.dll http://clients2.google.com/cr/symbol
Uploaded symbols for windows-x86_64/eventlog_provider.dll.pdb/47A0FB6E2BE14D53BCA8D063CFFE1AAE1 (eventlog_provider.dll )
src\breakpad\symupload.exe --timeout 0 C:\b\build\slave\win64\build\src\out\Release_x64\eventlog_provider.dll http://clients2.google.com/cr/staging_symbol
Uploaded symbols for windows-x86_64/eventlog_provider.dll.pdb/47A0FB6E2BE14D53BCA8D063CFFE1AAE1 (eventlog_provider.dll )
Warning: No product name (flag --product) was specified for C:\b\build\slave\win64\build\src\out\Release_x64\eventlog_provider.dll
Warning: Could not get file version for C:\b\build\slave\win64\build\src\out\Release_x64\eventlog_provider.dll
Warning: No product name (flag --product) was specified for C:\b\build\slave\win64\build\src\out\Release_x64\eventlog_provider.dll
Warning: Could not get file version for C:\b\build\slave\win64\build\src\out\Release_x64\eventlog_provider.dll

Bruce: could you browser the symbol server to see if the files are present?

Could the fact that the .dll is missing a version resource be a problem? It should have one regardless.

I wanted to understand what was happening here so I looked at the symbol upload output from some recent official builds, piping it through grep to see how many references there were to eventlog_provider.dll.pdb:

Uploaded symbols for windows-x86/eventlog_provider.dll.pdb/9EF9B590D80F47D393D85A2F2B9B42371 (eventlog_provider.dll )
Uploaded symbols for windows-x86/eventlog_provider.dll.pdb/9EF9B590D80F47D393D85A2F2B9B42371 (eventlog_provider.dll )

I then searched for the "Uploaded symbols for" string and found that it was from "breakpad\src\tools\windows\symupload\symupload.cc" - so the symbols are being uploaded to breakpad, not to our symbol server. Mystery number one solved. I think I will change that message because it repeatedly confuses me, and others.

And for remoting_core.dll.pdb the output was:

Uploaded symbols for windows-x86/remoting_core.dll.pdb/9E0408EDDE7142F8A657CD985BEB63991 (remoting_core.dll 58.0.2994.0)
Uploaded symbols for windows-x86/remoting_core.dll.pdb/9E0408EDDE7142F8A657CD985BEB63991 (remoting_core.dll 58.0.2994.0)
Uploaded symbols for windows-x86/remoting_core.dll.pdb/9E0408EDDE7142F8A657CD985BEB63991 (remoting_core.dll 58.0.2994.0)
Uploaded symbols for windows-x86/remoting_core.dll.pdb/9E0408EDDE7142F8A657CD985BEB63991 (remoting_core.dll 58.0.2994.0)
[01:39:23] Extracting source for remoting_core.dll:588B0708da8000 remoting_core.dll.pdb:9E0408EDDE7142F8A657CD985BEB63991
chromium_utils.MaybeMakeDirectory(C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991)
[01:39:23] chromium_utils.CopyFileToDir(C:\b\build\slave\win-pgo\build\src\out\Release\remoting_core.dll.pdb, C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991)
[01:39:23] pdb_index.UpdatePDB(C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991\remoting_core.dll.pdb, verbose=False, build_dir=C:\b\build\slave\win-pgo\build\src\out\Release, toolchain_dir=C:\b\depot_tools)
[01:39:36] Compress symbols: C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991\remoting_core.dll.pdb
Waiting for C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991\remoting_core.dll.pdb to finish ...
C:\b\build_internal\scripts\slave\.recipe_deps\build\scripts\slave\gsutil.bat cp file://C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991\remoting_core.dll.pd_ gs://chromium-browser-symsrv/remoting_core.dll.pdb/9E0408EDDE7142F8A657CD985BEB63991/remoting_core.dll.pd_
C:\b\build\slave\win-pgo\build>call python C:\b\build_internal\scripts\slave\.recipe_deps\build\scripts\slave\..\..\..\depot_tools\gsutil.py -- cp file://C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991\remoting_core.dll.pd_ gs://chromium-browser-symsrv/remoting_core.dll.pdb/9E0408EDDE7142F8A657CD985BEB63991/remoting_core.dll.pd_
Copying file://C:\b\build\slave\win-pgo\build\src\out\Release\symsrc\remoting_core.dll.pdb\9E0408EDDE7142F8A657CD985BEB63991\remoting_core.dll.pd_ [Content-Type=application/octet-stream]...

Okay, so some steps are being missed for eventlog_provider.dll.pdb. A bit of sleuthing through Chrome and internal build source suggests that the list of binaries to be upload actually comes from this line of Python:

    binaries = fparser.ParseGroup('symsrc')

This triggers source indexing and uploading to the symbol server. The 'symsrc' tag is applied to a binary, not to its PDB, and it is not applied to eventlog_provider.dll. It's all very non-obvious and cryptic.

This is not a DLL that needs source indexing and the behavior is now understood so I don't think we should change anything, except perhaps the documentation. Clearly we need to make it easier to understand how to control this. But where should this documentation go? Any ideas?

I feel better now that I understand what is going on.

The following revision refers to this bug:
  https://chromium.googlesource.com/breakpad/breakpad/+/76a48f4aa9daf2fc0e601f82acd4138df8d2c3fd

commit 76a48f4aa9daf2fc0e601f82acd4138df8d2c3fd
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Sat Jan 28 02:47:17 2017

Change symbol upload message to include 'breakpad'

The breakpad symbol uploader prints messages of this form:

    Uploaded symbols for windows-x86/eventlog_provider.dll.pdb/...

This is confusing because many people see this message and assume that
symbols are being uploaded to a symbol server. This changes the message
to clarify what is happening.

BUG= 677226 

Change-Id: Id6fdd8497d0cb97be43c4af010058aab9d84375c
Reviewed-on: https://chromium-review.googlesource.com/434187
Reviewed-by: Mark Mentovai <mark@chromium.org>

[modify] https://crrev.com/76a48f4aa9daf2fc0e601f82acd4138df8d2c3fd/src/tools/windows/symupload/symupload.cc

Thanks for the thorough investigation Bruce!