src/SizeBench.AnalysisEngine/PE/PEFile.cs : 511
thunk32 deref twice (use nameTableThunkRva) but only once (use nameTableThunkPtrRva) need

delayLoad.zip

Describe the bug
I cannot compose column sorting in SizeBench, because it uses unstable sorting for sorting by column.

What you are doing

1. Open a binary for inspection
2. Select "Start Exploring By Compilands"
3. Sort results by specific column, e.g. Size on Disk
4. Sort results by different column, e.g. Lib Name

Expected behavior
I want the rows to be sorted by Lib Name and within single lib, by their size on disk.

What actually happens is that I get rows sorted by Lib Name and otherwise jumbled, so I can't go after largest obj files in given lib, which is what I want to do.

Environment Details

• OS: [type ver at the Windows Command Prompt]: [Version 10.0.19044.1889]
• SizeBench version number [Go to Help > About SizeBench]: 2.2204.1800.0 (git commit b5c2b2ea)

Additional context
While my original use case is specifically grouping by lib, sort by size on disk, using stable sort when sorting by column will allow users to compose their own sorting orders arbitrarily.

When looking at large PDBs (like msedge.dll.pdb, chrome.dll.pdb) sizebench can take hours on my heavy duty dev box. Seems like there is an opportunity for performance improvement by utilizing more cores.

For example, the below has been running for 15 hours.

I did a build, and saw this warning:

  MSBUILD : warning MSB5029: The value "\**\*" of the "Include" attribute in element <ItemGroup> in file "C:\src
\github\SizeBench\src\Directory.Build.targets (53,11)" is a wildcard that results in enumerating all files on th
e drive, which was likely not intended. Check that referenced properties are always defined.

Directory.build.targets has a line that does this:

    <None Include="$(MicrosoftDebuggingDataModelDbgModelApiXtnPath)\**\*" CopyToOutputDirectory="PreserveNewest" Visible="False" Link="%(RecursiveDir)%(FileName)%(Extension)"/>

which means that MicrosoftDebuggingDataModelDbgModelApiXtnPath must be empty.

Protecting it with a check ('$(MicrosoftDebuggingDataModelDbgModelApiXtnPath)' != '') fixed it for me:

  <!-- This is all the stuff necessary to use DbgX at runtime, it's needed in multiple projects, so it's centralized here -->
  <ItemGroup Condition="'$(IncludeDbgXAssets)'=='true' And '$(MicrosoftDebuggingDataModelDbgModelApiXtnPath)' != ''">
    <Content Include="..\ExternalDependencies\DIA\msdia140.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <None Include="$(MicrosoftDebuggingDataModelDbgModelApiXtnPath)\**\*" CopyToOutputDirectory="PreserveNewest" Visible="False" Link="%(RecursiveDir)%(FileName)%(Extension)"/>
  </ItemGroup>

I'm not entirely sure why MicrosoftDebuggingDataModelDbgModelApiXtnPath isn't set, but this fixes it for me.

It looks like I don't have permissions to create a Pull Request.

I have found a bug in Sizebench (the version downloaded from the Microsoft AppStore, I did not try to compile a version from source). The bug happens when compiling an executable or dll with VC2017, when in one translation unit an unnamed namespace exists with a virtual class, and in another translation unit an unnamed namespace with an enum with the same name. The following is a minimal example. If you rename NameClash in either file to something different, the problem no longer occurs.

-------- virtualstruct.cpp --------

namespace
{
    struct NameClash
    {
        virtual ~NameClash() = default;
    };
    NameClash instance;
}

-------- main.cpp --------

namespace
{
    enum NameClash { FOO };
}

int main(int argc, char ** argv)
{
    NameClash t = NameClash(argc);
    if (t == FOO)
        return 1;
    else
        return 0;
}

When you compile this with Visual Studio 2017, and open the resulting executable with Sizebench, you get a dialog with an error message "Error opening binary! - There was an error opening this binary or PDB", following by a link to some log, and a call stack.

I have found out that this problem does not occur when compiling the same files with Visual Studio 2022.

I'll try to attach a screenshot, the content of the log file, and a zip file with the project file, which can be used with Visual Studio 2017 to compile and reproduce the bug.

tmpAD61.tmp.sizebenchlog.txt

sizebenchbug.zip

Describe the bug
If I go to Help > About SizeBench, I can't copy the version. This makes it needlessly annoying to file out bug reports against SizeBench.

Expected behavior
I can copy the version number just as I can copy the text in "Product details" field.

Environment Details

• OS: [type ver at the Windows Command Prompt]: [Version 10.0.19044.1889]
• SizeBench version number [Go to Help > About SizeBench]: 2.2204.1800.0 (git commit b5c2b2ea)

Describe the bug
When using features that require the debugging engine, SizeBench loops forever in "Initializing debugging engine" state.

What you are doing

1. Download and install latest release from Windows Store.
2. Run an analysis on a single binary. In my case this is C++ built with MSVC 2022 17.6.3, 50 MB exe and ~900 MB pdb.
3. Select template foldability analysis
4. In results, try to fall inside any record

It also reproduces with other features that require debugging engine.

Expected behavior
Either to have all necessary things installed with SizeBench or to provide meaningful error message with instructions for fixing an issue on user side.

Screenshots

Environment Details

• OS: Windows 11 21H2 (22000.2057)
• SizeBench version number 2.2302.2300.0 (git commit 91c1cfe)
• Examined binary is built with MSVC 2022 17.6.3 and linked with Microsoft linker

Additional context
Application loops but doesn't hang, i.e. it responds to the input. I can use File and Help menus and open About SizeBench. Modal popup with "Initializing debugging engine" has a clickable X button but nothing happens on click. The longest trial is around 30 min with no progress. SizeBench.GUI.exe uses 0-1% of CPU. Memory consumption doesn't change.

Describe the bug
Using the "pick pdb" path, the code is supposed to hunt around to find a .dll nearby when the PDB path is chosen. This hunting does not happen.

What you are doing

1. Start a new single-binary session
2. Pick a PDB

Expected behavior
After picking a PDB with a DLL next to it, the "Binary path" field should auto-populate.

Environment Details

• Windows 11
• Version 1.0.0.0 git commit 2450ddc-dirty

Additional context
The callstack instantiating SelectSingleBinaryAndPDBControlViewModel is in the Windsor module. It ends up synthesizing a zero-length IBInaryLocator parameter to the constructor, causing InferBinaryPathFromPDBPathIfPossible to skip the mapping step.

While tracking down mysterious binary bloat, I found a bunch of new .rdata in my DLL. They are all strings that look like symbols of code, but my binary has RTTI turned off.

It took a bit of digging:

• Use the RVA from sizebench
• Use link -dump -disasm -all -bytes thedll.dll > myfile.asm
• Search for the RVA in the asm file to get a symbolic name
• Search for the symbol in the asm file to find references

So two features in one:

Show the RVA symbolic name if it exists

In the view for the item, show both the gross-name and the decoded name if possible.

Provide a clickable link of functions that reference the symbol

This might be very costly to produce, but it would have made my life very easy. If the RVA is referenced in code, provide a link to the function disassembly that uses it. Bonus points for scrolling the listing and highlighting HERE IT IS for easy finding.

I took SizeBench and removed the DIAAdapter.cs: linkerCommandLine is not MSVC_LINK_CommandLine check.
Tested one of my projects which is linked with LLVM Linker.

It hits the The gap between COFF Groups ... - a gap this large has not been observed before so it may indicate a bug in SizeBench check in BinarySection.cs.
Not sure this is related to LLVM Linker differences per se, but I removed that check as well.

Now SizeBench is perfectly usable for my project and provides helpful information.

I propose:

• Drop the "MSVC Linker" hard requirement, possibly just warn instead.
• If there is information missing in LLVM Linker output that would be helpful for SizeBench, create issue in LLVM project github.
• Drop the InvalidOperation exception for large gaps between COFF groups, just warn instead.

This does not exist: https://github.com/microsoft/SizeBench/blob/main/docs/Contributing.md

Describe the bug
I was using the "wasteful virtuals" heuristic to try and optimize a large binary. The "virtuals with no overrides" list specifically is easy gains. However, one of the methods flagged does have overrides and removing the virtual keyword introduced a build break.

On closer inspection the problem seems to be that the virtual method and the override has at least one other derived class in the middle.

The heirarchy is roughly as follows:

class A
{
public:
   virtual void DoStuff() { }
};

class B : public A
{ };

class C : public B
{
public:
    void DoStuff() override { }
};

In this case A::DoStuff is considered a wasteful virtual even though C::DoStuff overrides it. Removing the virtual keyword will introduce a build break.

Expected behavior
This method should not be considered wasteful.

Screenshots
N/A

Environment Details
OS is Windows 11.
SizeBench is latest version from the Store at this time (on a different device so I don't have the exact version handy).

Additional context
N/A

In this view, the first line difference is only in the source file - this DLL pulls in static libs that use the same cppwinrt version, but different runs of its projector, so it's got both lib1/obj/winrt/base.h and lib2/obj/winrt/base.h. The second difference is actually meaningful (comparing IIDs in queryinterface.)

I'd like to fix the diff view to either ignore the file-path difference in the view, or mask the "noncommon source base path" so only the real differences in code are shown.

Describe the bug
SizeBench duplicate data advice is inaccurate. Inside the duplicate data feature, SizeBench says that "Changing to const 'constexpr' or 'const' or 'extern __declspec(selectany) const' will save copies.". This is only partially true depending on which language the user's project is written in. In Chromium's case, it is written in C++ where both const and constexpr symbols defined inside classes are implied to be static. The only part of the suggestion which works in Chromium's case is '__declspec(selectany) const'.

Expected behavior
SizeBench should give advice based on which language the user's project is written in. At the very least, it should have a warning that the current suggestions aren't for C++. This would prevent users from potentially losing development time on C++ projects.

Screenshots
SizeBench suggestion after opening duplicate data feature
Text:
These chunks of data are marked as 'static const' or in some cases just 'const' and have ended up with multiple copies of their data in the binary. Typically you'll see one copy per translation unit referencing the symbol. Changing to 'extern __declspec(selectany) const' will save copies.

SizeBench suggestion after opening a symbol in duplicate data feature
Text:
This symbol is duplicated between multiple compilands - the most common cause of this is that it is marked 'static const' and would be better off marked as 'const' or 'extern __declspec(selectany) const'. With the way it is defined now, it is wasting space in the binary with the same data in multiple locations.

Environment Details

• OS: Microsoft Windows [Version 10.0.19044.2130]
• SizeBench version number: 1.0.0.0

Additional context
N/A

Describe the bug
SizeBench will fail to analyze a binary if it thinks incremental linking was used. Some sets of linker options will preclude incremental linking but SizeBench doesn't realize this. The result is that it will reject analysis of a binary that would otherwise be compatible.

This change to BinSkim encodes more of the incremental linking rules in code and could serve as a good reference: microsoft/binskim#667.

The official docs are here: https://docs.microsoft.com/en-us/cpp/build/reference/incremental-link-incrementally?view=msvc-170#remarks.

Is your feature request related to a problem? Please describe.
The disassembly view in template foldability is useful for seeing how templates are very similar but slightly different. It has the file name and line number in the disassembly. However, the text cannot be selected and therefore cannot be copy/pasted to a text editor to view the source code.

Describe the solution you'd like
The text in this view should be selectable and support copying.