Symbol server PE files are being overwritten with different versions about windows-dev-performance

[randomascii]

I've put the relevant files (three copies of kernel32.dll and a crash dump that will happily refer to any one of them) in this shared Google drive folder:
https://drive.google.com/drive/folders/1EUGs6iNqNXvWb98KMYcSBbXzIXUWGoWw

[zooba]

Thanks, I'm seeing if I can chase down someone who may know what's going on here. This seems bad, though there may be a legitimate reason for it.

I assume you've got the latest windbg available?

[randomascii]

Yeah, I tried this with the latest windbg, but it won't matter because it's the timestamp/image-size/name triplet reuse that is the problem. I can reproduce the issue using RetrieveSymbols.exe (https://github.com/google/UIforETW/blob/main/bin/RetrieveSymbols.exe) but also I can see that I have three different files with the same timestamp/image-size/name triplet, and once that is true there is nothing that windbg or any other symbol-server client can do.

[randomascii]

This has been reported as a problem in the past, such as here, where it causes (understandably) developer confusion:

m417z/winbindex#139

[AvriMSFT]

Hey @zooba! Any updates here?

[rhuijben]

Any news half a year later? @AvriMSFT @zooba?

[zooba]

The Windows build team acknowledged that they're doing it, but I don't know how much further it got than that. If it's still happening, probably didn't go anywhere. I'll see if the people I was in touch with are still on it.

[AdamBraden]

Closing the loop here - this was resolved over the summer. Let us know if something is not working right.

[randomascii]

By "resolved" does this mean that files will not be overwritten anymore? As in, retrieving PE files from the symbol server should now retrieve the correct version? That would be great.

[m417z]

It would indeed be interesting to see how it was resolved. I still see the same issue in recent files. For example:
wiatrace.dll: https://winbindex.m417z.com/?file=wiatrace.dll
Versions 10.0.19041.3570 and 10.0.19041.3636, x64 architecture.
The hashes are:

• f13e3850767d8841ca9b1fb68aabcc195efff0ab9300d3e5ad68435a596092f7
• c52a5424d7a109d73739e20e71fa58744de6bb19ff1357f36e07505dd2e90ca6

Both files have the same timestamp and image size, so the link for both files is:
https://msdl.microsoft.com/download/symbols/wiatrace.dll/00EA0FC7a000/wiatrace.dll

The files were published in October 10 and 26, respectively, so after "this summer", I assume.

[zooba]

It's been resolved, but only in the current branch (at the time, a few months ago). So build 19041 (Windows 10 April 2020 update) is not going to have the correction, but newer builds should be fine. I understand the issue is inherently part of the build process, rather than the server implementation.

[m417z]

Here's another example:
wiatrace.dll: https://winbindex.m417z.com/?arch=insider&file=wiatrace.dll
Versions 10.0.23619.1000 and 10.0.23620.1000, x64 architecture.
The hashes are:

• 4541a5506fb6b82becaf9fcb00ede0261305a018bcf1f218e5819246c341bbc2
• a493b3d2efe6a98c00ec191cd0f53226c52bb8dc050b9b345a4db2a6738665d0

Both files have the same timestamp and image size, so the link for both files is:
https://msdl.microsoft.com/download/symbols/wiatrace.dll/C5004E2Ba000/wiatrace.dll

The files were published in January 18 and 25, 2024, respectively. How new should they be to have the fix? I'm also curious how the fix was implemented, any details about that?

[zooba]

I don't have the exact number, but I believe the fix is somewhere during the 10.0.25???.? version numbers, so anything before that is likely to keep showing it (as the fix is not in those branches), while newer builds should have updated timestamps to match the changed version number.