[acqq]

> Deleting the God Mode folder fixes the problem, because that is the only filesystem object for which GetDisplayNameOf() returns a malformed structure.

I wouldn't call it "malformed" -- the OS simply returned a null pointer: "the field that is supposed to point to the buffer containing the resulting string is NULL." Which in C means "nothing there." And the Java native interface code didn't check for that (it could have returned an empty Java string in that case), but dereferenced the null pointer instead. "Fail fast" indeed.

[dleskov]

Problem is, the God Folder dates back to Vista and it is the Windows 10 Creators Update that began setting that field to NULL. Apparently the author of that change did not foresee any backward compatibility issues.

[acqq]

See my other comment for the details, I believe now that the field was actually not set to null, the returned structure has a union which is documented to be able to be of different types. It's surely the type STRRET_CSTR that wasn't covered by Java, the API is then valid before and after the update, returning the structure with STRRET_CSTR and zeroes in the union is valid.

[ryandrake]

If we're talking about this [1] call, then it could be argued that it's malformed. Unless I missed it, the documentation does not specify that a NULL pointer may be returned there. Defensive programming practice says it's wise to check for NULL, but the function, as documented, would appear to be behaving incorrectly.

1: https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...

[acqq]

Looking this more carefully, I guess the pointer to the STRRET always remains valid but whoever implemented the decoding of STRRET didn't cover all the cases of uType, and the GodMode had a different uType than others that the developers tested? In that case instead of the pointer to null the API actually returned an empty string (uType STRRET_CSTR actually then means that what would be a null pointer are actually the bytes of the string, and being zero, the string is empty, saving one allocation), but the returned structure wasn't properly understood by the caller.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...

That would mean the API behaved according to the specs. See an example here, it's impossible for the call to destroy the pointer to STRRET:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...

[ryandrake]

You're probably right. Looks like the article mentions it fills in the structure, not setting the pointer to NULL (which as you point out would be impossible because it's not a pointer to a pointer).