Scott Hanselman

Interesting bugs - MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small.

August 30, '18 Comments [8] Posted in DotNetCore
Sponsored By

I got a very strange warning recently when building a .NET Core app with "dotnet build."

MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. 
Image is too small.

Interesting Bug used under CC https://flic.kr/p/4SpmL6Eek! It's clear, in that something is "too small" but what? A file I guess? Maybe it's the wrong size?

The error code is MSB3246 which is nice and googleable/searchable but it was confusing because I couldn't figure our what file specifically. It just felt vague.

BUT!

I had recently been overclocking my machine (overly aggressively, gulp, about 40%) and had a very nasty hard reboot. As a result I had a few dozen files get orphaned - specifically the files were zero'ed out! Zero is small, right?

Turns out you can pass parameters over to MSBuild from "dotnet build" and see what MSBuild is doing internally. For example, you could

/fileLoggerParameters:verbosity=diagnostic

but that's long. So how about:

dotnet build /flp:v=diag

Cool. What deep logging do I see now?

Primary reference "deliberately.zero.bytes.dll". (TaskId:41)
13:36:52.397 1:7>C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
Resolved file path is "S:\work\zero-byte-ref\deliberately.zero.bytes.dll". (TaskId:41)
Reference found at search path location "{RawFileName}". (TaskId:41)

Now with "verbose" turned on I can see that one of the references is zero'ed out/corrupted/bad. I reinstalled .NET Core in my case and doubled checked all the DLLs/Assemblies that I was bringing in - I also ran chkdsk /f - and I was back in business!

I hope this helps someone who might stumble on error MSB3246 and wonder what's up.

Even better, thanks to Rainer Sigwald who filed a bug against MSBuild to update the error message to be more clear. In the future I'll be able to debug this without changing verbosity!


Sponsor: Preview the latest JetBrains Rider with its built-in spell checking, initial Blazor support, partial C# 7.3 support, enhanced debugger, C# Interactive, and a redesigned Solution Explorer.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Saturday, 01 September 2018 04:50:50 UTC
Have asked many many times for the name of a missing file when loading an exe where a nested doll does not exist

Have asked many times to get th field name causing an exception when initializing an object

Devops is sold Sa cure but is not followed in the compiler or visual studio

Had to attach visual studio debugger to another visual studio instanc to catch a compiler exception

John
Saturday, 01 September 2018 16:40:19 UTC
Huh. It's worrisome that a random reboot corrupts the filesystem -- haven't seen that on Windows for, like, at least ten years... (Verbose logging is cool though :) )
Max
Sunday, 02 September 2018 00:48:40 UTC
Another common reason for this error message is that native DLLs shouldn't be placed inside a lib/ folder in NuGet packages, but rather runtime/ (sub-)folders. Full framework MSBuild doesn't care but Core MSBuild (dotnet CLI) does - different APIs used for inspecting the .dll file AFAIK.
Previously, some projects did this to ship native DLLs.
See on StackOverflow
Sunday, 02 September 2018 20:53:43 UTC
Scott, are you referencing the error from the Salesforce library conversion to .NET Core live stream?
Robert G
Tuesday, 04 September 2018 23:15:59 UTC
Robert - Exactly right!
Scott Hanselman
Saturday, 08 September 2018 06:35:32 UTC
Yes Exactly right! This is such a great resource that you are providing and you it away for free. I love seeing blog that understand the value. i also write articles about technology and i post daily here's my website Daily Techie News and here's my latest article Cheapest Phone with in display fingerprint sensor if you are tech savvy then you can check my website.
Monday, 10 September 2018 02:43:41 UTC
The level of verbosity "diagnostic" is almost unreadable because it contains to much text. However you can use the binary logger to get the same data but in a readable way: Exploring the MSBuild log using the binary log viewer
Tuesday, 11 September 2018 05:07:41 UTC
Scott,

How come developer tools don't get the same level of reliability as does SQL Server?

No one would buy SQL Server if your only upgrade path every 3 years is to edit config files, rewrite c# code, rebuild your server machine, update all of your SQL queries, install and learn 10 different new open source software of unknown reliability.

Why does MS development not get held to the same quality, upgrade path and stability standard as SQL Server?

It's costing my large team thousands, if not tens of thousands, of dollars in lost money every year.

Please help.
Ronald
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.