Crash when Attempting to Decompile Microsoft.Exchange.Monitoring.ActiveMonitoring.Local.Components.dll And Stops All Decompilation #2622
Comments
The path is exactly 260 characters long... I don't have access to Windows 11 yet. Not sure, if Long Path Support is enabled by default. You might have to enable it by creating a REG_DWORD registry key named "LongPathsEnabled" with value 0x1 at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" (see https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation for more information). These instructions are for Windows 10, I am not sure if something (or what) changed in Windows 11. The second exception is a decompiler bug, which I will try to reproduce and fix. Thanks for reporting! |
…izer composed of readonly properties.
Thanks, will see if the LongPathsEnabled setting works, as I don't think that is enabled by default and near as I can tell Windows 11 shouldn't have changed that I don't think? Appreciate your work on a fix! |
|
Sorry closed this as I thought it was working but whilst the issue is fixed if I do an individual file decompile its still occurring if I try decompile multiple files at the same time with this DLL in it. |
|
Update: Seems like applying the regex fix from https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation that @siegfriedpammer mentions allows for successful decompilation on 7.2.0.6839-preview4 when batch decompiling multiple files into a solution. Therefore whilst the root issue is likely still there, this does work as a workaround in the meantime, and it also seems to still work on Windows 11. |
The root cause is the file system limitation, which we cannot (completely) and won't work around, because Microsoft already fixed it by introducing "Long Path Support" in their OS. As a workaround you could always set "C:\out" (or something even shorter) as output directory to maximize your chances of success. Any workaround from our side would mean crippling namespace names and filenames, which we decided is not a good idea. When long paths are not supported we limit the length of whole path to 250 characters and each segment to 30 characters (as you can see here: https://github.com/icsharpcode/ILSpy/blob/master/ICSharpCode.Decompiler/CSharp/ProjectDecompiler/WholeProjectDecompiler.cs#L559). Sorry! |
|
Ah fair point and thanks for linking to the code that makes a lot more sense 👍 Only thing I would say is that from a user perspective its kind of hard to know this might be an issue the way the interface and warnings currently are so I think adding a warning to the end user about this might be useful in case others run into similar issues, just as a quick debugging tip. Otherwise happy to have this issue closed, and appreciate your patience and help on this! |
Unfortunately the exceptions thrown in these cases are not very descriptive (in your case it was reported as We show the following message in that case:
However, System.IO unfortunately is a bit messy in this case. I suspect this is because "Long Path Support" was bolted onto it at a relatively late stage in the product life-cycle and it seems they missed the "is the path too long? throw new PathTooLongException();" in some cases. Anyway, do you consider this fixed? If yes, please close the issue, thanks! |
|
Thanks for the explanation, makes sense. Marking this as closed and resolved! |
Steps to reproduce
Error message shown
Details
The text was updated successfully, but these errors were encountered: