Receiving this exception when trying to load an lnk file.
The shortcuts are created by an installer, and the error only occurs on a remote computer (code is part of some tests).

I've copied the shortcut file here: https://drive.google.com/file/d/1DlCeylZZPW8FOoes6mG-1RgnHBPobJW4/view

System.ArgumentException : Source array was not long enough. Check srcIndex and length, and the array's lower bounds.
at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
at ExtensionBlocks.PropertyStore..ctor(Byte[] rawBytes)
at ExtensionBlocks.Beef0026..ctor(Byte[] rawBytes)
at ExtensionBlocks.Utils.GetExtensionBlockFromBytes(Int64 signature, Byte[] rawBytes)
at Lnk.ShellItems.ShellBag0X1F..ctor(Byte[] rawBytes) in D:\Code\Lnk\Lnk\ShellItems\ShellBag0x1f.cs:line 66
at Lnk.LnkFile..ctor(Byte[] rawBytes, String sourceFile) in D:\Code\Lnk\Lnk\LnkFile.cs:line 110
at Lnk.Lnk.LoadFile(String lnkFile) in D:\Code\Lnk\Lnk\Lnk.cs:line 17

There is a bug when using Lnk to process this shortcut. When using this in my application, it returns

System.OverflowException
  HResult=0x80131516
  Message=Array dimensions exceeded supported range.
  Source=Lnk
  StackTrace:
   at Lnk.ShellItems.ShellBag0X31..ctor(Byte[] rawBytes)
   at Lnk.LnkFile..ctor(Byte[] rawBytes, String sourceFile)
   at Lnk.Lnk.LoadFile(String lnkFile)
...

I am currently on Windows 11 Home Version 10.0.22621 Build 22621

Running a test on it via the project files, it returns

If an extra data block shorter than 4 bytes is encountered, an exception will be raised in the exception handling block:

                catch (Exception e)
                {
                    var dmg = new DamagedDataBlock(extraBlock,e.Message);
                    ExtraBlocks.Add(dmg);
                   
                }

since the constructor for DamagedDataBlock assumes that the data supplied will be at least 4 bytes long.

Hello - does this work with long paths containing over 260 characters?

I just traced an issue where some corrupt data triggered one of the Trace.Assert()'s in this code - on our Linux boxes, this just closes the running application - no possibility of handling any exceptions. At least, that's what I see, and the last time I looked into this when migrating to .NET Core, various Assert() methods call something like Environment.Exit() (iirc) - which leads to this.

I think the proper solution is to throw an exception so the caller can handle it.

For our use case, I'm commenting these traces out and replacing them with throws.

I think this line has an error - it's not consistent with the other definitions (but I'm not smart enough to know for sure...)

Hi Eric,

Today, I came across a new malicious lnk file and want to analyze it by "LNK" project. However, the sample throws exceptions while looping on lines of "extrabyte" code. I have attached a screenshot that includes of issue. Such malicious files are becoming more and more common and code fixing is essential to fighting them, and thank you in advance as well for your help and knowledge.

Download link for Malicious LNK sample: https://api.docguard.io:8443/Downloads/a92c49ff-6014-4b23-9f0a-733cc0f643cf/fe8fd4a9a8105b9052f2d29ab493613c69e1c6b3a8d34ee57c0c4e92b4fe483d.zip
Zip Password: infected

Regards,

How should the properties LocalPath and CommonPath be used? First I used LocalPath to get the target link of a linked directory, but then I saw that sometimes it isn't the full path. In my tests in was for example "D:\" and CommonPath contained the rest of the path.
I'm not sure why this applies only to a few of the directory link files. Maybe it has to do with the OS version they were created?! (Windows 7/8.1 instead of 10)
For now I use Path.Combine to combine those two. Is this the correct way? I didn't see a property that always contains the full target path.