Not registered yet?
Register now! It is easy and done in 1 minute and gives you access to special discounts and much more!
How do I enable assembly bind failure logging (Fusion) in .NET?
In my case helped type disk name in lower case
Wrong - C:\someFolder
Correct - c:\someFolder
Just in case you're wondering about the location of FusionLog.exe -
You know you have it, but you cannot find it? I was looking for FUSLOVW in last few years over and over again. After move to .NET 4.5 number of version of FUSION LOG has exploded.
Her are places where it can be found on your disk, depending on software which you have installed:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\x64
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I usually use the Fusion Log Viewer (Fuslogvw.exe from a Visual Studio command prompt or Fusion Log Viewer from the start menu) - my standard setup is:
Remember to turn of logging off once you're done!
(I just posted this on a similar question - I think it's relevant here too.)
Note that in cases where you are hosting the runtime yourself from a native application you will be required to use a custom log path for some reason otherwise you won't get anything logged.
At least in my situation, I didn't actually have to set the custom log paths. All I had to do was turn logging on, e.g., "Log all binds to disk" on the settings dialog.
Run as Administrator was required in my case, otherwise all options were disabled.
I have spent all day trying to figure out how to use this tool and you solved it!
If you are trying to use the Fusion Log Viewer in conjunction with Visual Studio I've found that I had to launch the log viewer and then restart Visual Studio as otherwise the viewer doesn't seem to log VS bind fails.
Note: create the folder as Admin!
Make sure you are running fuslogvw not only as admin but also from the correct Windows SDK path the Visual Studio project throwing the exception is using. Check its csproj and search for SDK within (my sdk node is named TargetFrameworkSDKToolsDirectory). Using a non matching fuslogvw version seems to not catch the exceptions (which makes sense...)
Thanks for the reminder to turn off logging once you're done. I assumed (very silly to just assume) that it only logged when running fusion log
Adding to @Veverke's comment: "Search everything" app says latest ones on my pc are under "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.1 Tools"; AFAIK using the highest listed SDK version is a good strategy (I don't think you need to use an OLDER fuslogvw, even if you are using an older VS.)
You can run this Powershell script as administrator to enable FL:
Set-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name ForceLog -Value 1 -Type DWord
Set-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name LogFailures -Value 1 -Type DWord
Set-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name LogResourceBinds -Value 1 -Type DWord
Set-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name LogPath -Value 'C:\FusionLog\' -Type String
Note: Ensure that the directory provided for the LogPath entry exists. If the directory does not exist, then your logs will not be retrievable.
and this one to disable:
Remove-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name ForceLog
Remove-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name LogFailures
Remove-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name LogResourceBinds
Remove-ItemProperty -Path HKLM:\Software\Microsoft\Fusion -Name LogPath
Thanks! I've allowed myself to put your commands into this gist. And I added creation of the c:\FusionLog dir so that people don't forget that ;-)
Command line rules! I could quickly replay this using the best invented so far code reusability technology called "cut and paste". Thanks.
Add the following values to
DWORD ForceLog set value to 1
DWORD LogFailures set value to 1
DWORD LogResourceBinds set value to 1
DWORD EnableLog set value to 1
String LogPath set value to folder for logs (e.g. C:\FusionLog\)
Make sure you include the backslash after the folder name and that the Folder exists.
You need to restart the program that you're running to force it to read those registry settings.
BTW, don't forget to turn off fusion logging off when not needed.
Gary's solutions worked for me although I also had to follow by resetting IIS. Note I configured this in a clean environment where I didn't want to install SDKs and the like.
I added those entries, but my c# express (2010) still tells me "Assembly binding logging is turned OFF". How to make it work?
Been reported by some that registry change does not take right away. Have you tried turning Fusion logging on then rebooting?
You need to restart whatever program it is you're running for it to read those registry settings
Where exactly is the HKEY_LOCAL_MACHINE folder located?
@ArtF: That's a location in the registry.
The Fusion Log Viewer does all that for you. Go to Start -> Programs -> Visual Studio xxxx > Visual Studio Tools > Visual Studio Command Prompt (run as admin) and type "fuslogvw". In Settings you adjust the logging.
To turn on/off logging handy, I've created .reg files, which are based on Gary Kindel's answer: enabling and disabling.
Enabling fusion log can have severe performance impact over time. My Visual Studio experience deteriorated over time, only to find that fusion logging was enable. Remember to disable it after use.
When using Fusion Log on Azure machine make sure to put log files on the same disk as application. Ex. web app is deployed to F:\sitesroot\0. Log to `F:\fusionlog`. Create that dir before.
@r3mark It doesn't put the trailing slash for the folder though.
But.. REMEMBER TO TURN IT OFF. I just lost a day troubleshooting slow IIS, and it's due to me turning on Fusion Logging but not turning it off. 10 Gb of files later.... Procmon.exe saved the day.
The "EnableLog=1" is missing from this list.
From my experience, you should NOT put this under the Wow6432Node key, even if your application runs 32-bit.
If you don't disable logging, it starts taking gigs in a short amount of time.
Instead of using a ugly log file, you can also activate Fusion log via ETW/xperf by turning on the DotnetRuntime Private provider (Microsoft-Windows-DotNETRuntimePrivate) with GUID 763FD754-7086-4DFE-95EB-C01A46FAF4CA and the FusionKeyword keyword (0x4) on.
echo Press a key when ready to start...
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -on PROC_THREAD+LOADER+PROFILE -stackwalk Profile -buffersize 1024 -MaxFile 2048 -FileMode Circular -f Kernel.etl
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -start ClrSession -on Microsoft-Windows-DotNETRuntime:0x8118:0x5:'stack'+763FD754-7086-4DFE-95EB-C01A46FAF4CA:0x4:0x5 -f clr.etl -buffersize 1024
echo Press a key when you want to stop...
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -start ClrRundownSession -on Microsoft-Windows-DotNETRuntime:0x8118:0x5:'stack'+Microsoft-Windows-DotNETRuntimeRundown:0x118:0x5:'stack' -f clr_DCend.etl -buffersize 1024
timeout /t 15
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -stop ClrSession ClrRundownSession
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -stop
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -merge kernel.etl clr.etl clr_DCend.etl Result.etl -compress
When you now open the ETL file in PerfView and look under the Events table, you can find the Fusion data:
@YuriBondarchuk this activates it on demand and you have more data in the ETL (other processes, fileversion data) so that you can give the files t other users and they can get MUCH more information compared to the normal fusion log
Just a tiny bit of info that might help others; if you do something along the lines of searching all assemblies in some directory for classes that inherit/implement classes/interfaces, then make sure you clean out stale assemblies if you get this error pertaining to one of your own assemblies.
The scenario would be something like:
In short: A ---loads--> B (stale) ---references---> C
If this happens, the only telltale sign is the namespace and classname in the error message. Examine it closely. If you can't find it anywhere in your solution, you are likely trying to load a stale assembly.
Set the following registry value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion!EnableLog] (DWORD) to 1
To disable, set to 0 or delete the value.
[edit ]:Save the following text to a file, e.g FusionEnableLog.reg, in
Windows Registry Editor Format:
Windows Registry Editor Version 5.00
Then run the file from windows explorer and ignore the warning about possible damage.
Not that the entry probably won't exist - you'll have to create it. At least, I did when I was about to answer this question just before the crash this morning :)
What does the ! mean? Key or value? What about 64 bits systems?
this doesn't actually work. the value is ForceLog not EnableLog, and there is an additional step needed here (see: thepursuitofalife.com/…)
actually, this does work...you just need to run iisreset afterwords to get it to work.
iisreset? Really? Why would you reset IIS to get Fusion bind logging to work?
@Norman: Because this particular setting is used to make the Asp.Net errors show assembly binding error messages in the error pages, not to save the logs to file. @OP: +1. Edited to include a .reg file. The ! format is one I had never seen, except in the error message that sent me to this page looking for answers.
You don't need to reset IIS – just the relevant application pool. Or at least that was all I needed to do.
what is Windows Registry Editor Format: ?
Marchy's link should go to docs.microsoft.com/en-us/previous-versions/dotnet/…
If you have the Windows SDK installed on your machine, you'll find the "Fusion Log Viewer" under Microsoft SDK\Tools (just type "Fusion" in the start menu on Vista or Windows 7/8). Launch it, click the Settings button, and select "Log bind failure" or "Log all binds".
If these buttons are disabled, go back to the start menu, right-click the Log Viewer, and select "Run as Administrator".
Those buttons are disabled for me - why?
@Tim, not seen that before - could it be to do with Admin privileges? It is HKEY_LOCAL_MACHINE that is being modified after all.
"Settings, Log bind failures" was enough to find my problem.
Make sure the folder allows write access. UAC and c:\logs do not play nice with the fusion log
Just as a note, if the buttons are disabled, re-run fusion log viewer with admin privileges.
If you aren't seeing any output Reboot your PC. I experienced this with .NET 4.6 + VS2015 on clean PC just with .NET 4.6 tools folder copied over. Note if you are told errors about the custom path when you set it (and you think it's telling you lies) press OK on the settings dialog a few times anyway and it'll ignore the error.
As I wrote in a comment to @MikeGoatly's answer, I think you need to make sure you are picking the correct fuslogvw.exe, from the correct Windows SDK folder. Check which SDK folder is in use by looking into the .csproj of the project you are running.
If you already have logging enabled and you still get this error on Windows 7 64 bit, try this in IIS 7.5:
Create a new application pool
Go to the Advanced Settings of this application pool
Set the Enable 32-Bit Application to True
Point your web application to use this new pool
The Fusion Log Settings Viewer changer script is bar none the best way to do this.
In ASP.NET, it has been tricky at times to get this to work correctly. This script works great and was listed on Scott Hanselman's Power Tool list as well. I've personally used it for years and its never let me down.
ps MAKE SURE you disable it after running or this folder could get quite large
this is why I use ETW, to only log data if I really need them, not all the time in an ugly large log file.