This is clearly an invalid instruction.
But observe that the offset is +2,
which is normally the start of the function,
because the first two bytes of Windows operating system
functions are
a mov edi, edi instruction.
Therefore, the function is corrupted.
Lets look back two bytes to see if it gives any clues.

@NotThisMind: It is jumping from a low-level usermode dll to a function in another dll that is not a part of Windows. For file APIs it generally goes kernel32 -> kernelbase -> ntdll -> kernelmode, this is just something you learn over time by debugging different issues.

Like Raymond said, normally the first two bytes of a Windows function are a mov edi, edi instruction, but in this case it's a jump to a different function with a "Mine_" name. Looks like IoLog overwrote the function with a jump to their own version.

@genumi, the instruction is clearly invalid because it is performing direct hardware access, and in Windows, direct hardware access should only happen in kernel mode (besides the fact that this particular function has no business doing hardware access, which it should be delegating to the storage stack, in order to support all manner of different filesystems and busses, including network shares).

You mean using an invalid instruction and catching the resulting exception to do something funky? I really don't see the point in doing that. I don't know how you would inject the exception frame in every application that would indirectly execute that invalid instruction.

I was a bit confused by the title "Access violation on nonsense instruction", until I realized it belongs to a series of articles. Attempting to execute IN and OUT instructions in user mode will raise a STATUS_PRIVILEGED_INSTRUCTION exception, unless a driver messes with the I/O permission bitmap (x86 specific, 32-bit only).

I am having great difficulty parsing this sentence: "But observe that the offset is +2, which is normally the start of the function, because the first two bytes of Windows operating system functions are a mov edi, edi instruction". I can't figure out what the "because" is referring to ("[x is happening/we have made deduction x] because the first two bytes of […]"), it doesn't seem to follow from the start of the sentence. Also, possibly due to my lack of debugger experience, I can't see where the +2 offset is shown here (maybe that's causing my parsing error?).

KERNELBASE!GetFileAttributesExW+0x2 shows that it is 2 bytes into the GetFileAttributesExW function. This is normally the real start of the function, because the first 2 bytes are taken up by "mov edi,edi" for reasons explained in the linked article. Because the offset is +2, it is fairly safe to assume that you're looking at an actual instruction in the function, not some constant value or anything else where you might expect it to be an invalid instruction.

I don't understand "Looks like a missing lock in IoLog". How could locking have helped? Surely no lock could have prevented a thread from executing GetFileAttributesExW while IoLog was doing its patching, unless IoLog did it at process startup while the LoaderLock was held (meaning you'd have to link against IoLog rather than loading it at runtime).

Isn't the correct thing to do write the JMP Mine_GetFileAttributesExW at GetFileAttributesExW-5 and then write JMP $-5 at GetFileAttributesExW+0?

I thought your name looked familiar – I used your books at my previous employer while porting an embedded system from XP to WES7.

"u" is for unassemble. You can see he specifically gives the address where it broke with a -2 to go back two bytes, which he knows is the beginning of the function. Unassembling from there he saw that the "ec" byte that was interpreted as a bad instruction was actually the third byte of a 5-byte instruction encoding a jump to a function in IoLog. The linked article gives a good explanation of how it should be done. But it still isn't supported. :-P

"I don't understand "Looks like a missing lock in IoLog". How could locking have helped?"

@Gabe It can't, his colleague didn't understand and Raymond either didn't continue the story with how he explained it to him or he didn't explain it to him at the time and he has just now pointed him to this article.

@FCotrina Read the earlier article where Raymond spends half of his time explaining that detouring OS functions is an OS feature. Meaning: Whether Windows on ARM or anywhere else uses or doesn't use detour shouldn't bother you at all, because you should not be doing anything with those points at all.

So why did the Windows on ARM guys decide that this internal feature wasn't worth it? Probably because the only legitimate reason to use it is never used in the first place (MS has't hotpatched the kernel for a long time) and it's now just another backwards compatibility constraint on Intel Windows because some programmers ignored the whole "for internal use only" part and just went ahead with it anyhow.

Really a win-win situation for them: Less effort and less things that people can screw up for them.

Note that you can detect image patching with the windbg !chkimg command. It compares the memory saved in a crash dump to the bytes that should be there (as retrieved from a symbol server). This only works, of course, if the patched memory is in the crash dump. Luckily most crash dumps save 256 bytes of memory around EIP (either on all threads or just the crashing thread, I'm not sure) so if the crash happens near where the patching occurred, !chkimg will detect it.

If the crash happens in a child function (due to the patching sending execution down a bad path) then !chkimg will not help, and in fact windbg will show the code bytes from symbol server, which makes things look really mysterious.