Porting ProcMonDebugOutput from C# to VBA
That's some pretty intense Win32 API stuff you got here, it's nice to see pointers and API calls in a VBA question, it's quite a change from the typical "speed up my Excel macro" question -- kudos!

One thing worries me though:


Dim Buffer As String
'Create a string buffer
Buffer = Space(200)
FormatMessage FORMAT_MESSAGE_FROM_SYSTEM, ByVal 0&amp;, Err.LastDllError, LANG_NEUTRAL, Buffer, 200, ByVal 0&amp;
Err.Raise Buffer



The first argument of Err.Raise should be an error number. If FormatMessage fills up buffer with a string that starts with an error number, then that's the error you're raising, and the rest of the message goes to oblivion. If the string does not start with a number, by VBA's implicit coversion rules you're raising error 0, which is a non-error... and that can't be right.

This instruction is redundant at first sight:


ProcMonDebugOutput = False



...but then, the function doesn't return a Boolean, but a LongPtr - why the Boolean assignment then? False would be implicitly converted to 0, which is the same value that would be returned if you didn't make that confusing assignment. I'd just remove it.

Same kind of issue here:


Dim outLen As Long
outLen = 0



outLen is already initialized with a value of 0, the assignment is redundant... and unless I missed something, the variable is assigned, but isn't used at all. I'd remove these two lines too.

I'll admit I didn't know you could specify ByVal at the call site to force a parameter to be passed by value (I wonder if it breaks the rubberduck parser... but that's my problem ;-) - I like it more than the parentheses-wrapping of the parameter to force ByVal for: it's more readable and less confusing - well done!

I can't seem to get a call-site ByVal to compile... will confirm in a few days when I'm on my laptop. Phone doesn't run VBA ;-)