Unhandle Exception in the search of the UI_root_address

[ApocalHyps]

Since yesterday I'm not able to run properly the read_memory program.

The program find candidates but fail after that:

Reading from process sample 77DA8F81EF96CDEC844EEC2605EB5CEE9CF73ECEDBB5B3B45FCEA2775124B471.\r\nFound 14 candidates for UIRoot in 64 seconds: 0x18A057F2978,0x18A057F3BA8,0x18A0CEA54F8,0x18A0CEB33E8,0x18A0F7ABD00,0x18A10093E40,0x18A100AB1A8,0x18A100AC420,0x18A100ADBE0,0x18A101358F0,0x18A10135BC8,0x18A161F1D68,0x18A5C956270,0x18A5DCCC128\r\n then I get into the stderr : Unhandled exception. System.ArgumentException: An element with the same key but a different value already exists. Key: ????\n

The return code is 3762504530

I already manage to get it working in the past few days but now it's impossible to run it, restart the game, the computer, changing the window type (fullscreen, fixed window) doesn't change anything.

I tried to run botlab and this issue affects it too.

Thank in advance

Best

EDIT

I have another sample that causes the same issue, not the same sample (the file 1Go): https://vu.fr/CNGJ

[Viir]

First thing I would check is the call stack given with the runtime exception.

When I have sample 77DA8F81EF96CDEC844EEC2605EB5CEE9CF73ECEDBB5B3B45FCEA2775124B471 I can investigate that failure. Where can I download that sample?

[ApocalHyps]

I added an edit in the original post so you can download the sample

[Viir]

Excellent, I found sample E71C45378C64BB353B40EE3F6FDA8961C63F87FDD7E18E126DD1BF3D75E82C71 using that link.

I got this output, so it looks like this sample is enough to reproduce the issue:

Reading from process sample E71C45378C64BB353B40EE3F6FDA8961C63F87FDD7E18E126DD1BF3D75E82C71.
Found 16 candidates for UIRoot in 129 seconds: 0x18A057F2978,0x18A057F3BA8,0x18A0CEA54F8,0x18A0CEB33E8,0x18A0F7ABD00,0x18A10093E40,0x18A100AB1A8,0x18A100AC420,0x18A100ADBE0,0x18A101358F0,0x18A10135BC8,0x18A161F1D68,0x18A5C956270,0x18A5DCCC128,0x18A7017BC28,0x18A7017BD60
Unhandled exception. System.ArgumentException: An element with the same key but a different value already exists. Key: ????

This will allow me to inspect further.

[ApocalHyps]

After further testing, I should note that for some obscure reason, finding the UI_Root address works when I'm in station but doesn't work when I'm "outside". Then I tried to use the root address I got when I was in station but it raised the exception again:

In station (sample collected when I was in station):

Reading from process sample A9B0A0D6D8F1ACB6779FEA4ED3659E5183E5EA1A4F7457D5E266FC4A7591384A.
Found 13 candidates for UIRoot in 37 seconds: 0x1929E3363D8,0x1929E3436B8,0x192A662A420,0x192A66A0908,0x192A66A7718,0x192A6FC02C0,0x192A6FCEA30,0x192A6FD5AF0,0x192A70A8EA0,0x192A70B2888,0x192A70B2B60,0x192AE0C7B00,0x192EBDA9F70
Read 2 UI trees in 8400 milliseconds:
0x192AE0C7B00: 875 nodes.
0x192A662A420: 1 nodes.
I found no configuration of an output file path, so I use 'C:\Users\Utilisateur\Documents\Eve Macro\read-memory\eve-online-memory-reading-254FB280B1.json' as the default.
I saved memory reading 254FB280B163378CC1242F8326C084E40F5D169AD4BE2D99A3EE62084E99ECD3 from address 0x192AE0C7B00 to file 'C:\Users\Utilisateur\Documents\Eve Macro\read-memory\eve-online-memory-reading-254FB280B1.json'.

Then I undock and try to use this address with .\read-memory-64-bit.exe read-memory-eve-online --pid=18392 --root-address=0x192AE0C7B00 and I got :

Unhandled exception. System.ArgumentException: An element with the same key but a different value already exists. Key: ????

I'm assuming it could have something to do with a setting on my game?

I can provide the process sample from when I'm in station if that can help. Let me know.

[Viir]

Thank you for the overview. That helps understand the issue. The error message from the first post led me to assume that the crash depends on a particular combination of dictionary entries in a single UI element, a node in the UI tree.

for some obscure reason, finding the UI_Root address works when I'm in station but doesn't work when I'm "outside".

The function to find the UI root integrates the function to parse the UI tree (including those dictionary entries) to rank candidates for the root. So it is expected that a crash in the tree parsing also affects finding the UI tree root.

Regarding differences between in-station and outside: There are even more apparent differences. For example, the stationWindow / (Python type name LobbyWnd) depends entirely on whether you are in a station. When you undock, the whole window disappears. So if there were an error-inducing combination in that window, you would see a crash when docking in a station.

I'm assuming it could have something to do with a setting on my game?

Game client settings can affect the presence of those dictionary entries, so that might be the case

For now, I assume sample E71C45378C64BB353B40EE3F6FDA8961C63F87FDD7E18E126DD1BF3D75E82C71 will be enough to implement a fix.

I would first look at where that runtime exception is coming from. I don't find a stack trace above.

In any case, this part looks to me like it could allow for such a runtime exception: https://github.com/Arcitectus/Sanderling/blob/6dce6453b4d8217b625e4bc4688177913352cc89/implement/read-memory-64-bit/Program.cs#L967-L969

[Viir]

This crash was fixed with https://github.com/Arcitectus/Sanderling/commit/01d165258d01b69be524efe2224806496ece3aa9

Thank you again for sharing the training data for your setup. It might help people with similar configurations too!