Porting ProcMonDebugOutput from C# to VBA

This code has one public method. ProcMonDebugOutput(). It will sent a string of text to Process Monitor that process monitor will display.

I'm basically ported this file.

I don't have a 64 bit version of office to test this on, but I think I used all the LongPtr right.

My two big concerns are:
* Are the Win32 API calls "correct". I know they're passing the right data, but should I fiddle with them to make more sense?
* Is my error handling appropiate?

```
Option Explicit

' Win32 API Constants
Private Const GENERIC_WRITE As Long = &H40000000
Private Const OPEN_EXISTING As Long = &O3&
Private Const FILE_WRITE_ACCESS As Long = &H2
Private Const FILE_SHARE_WRITE As Long = &H2
Private Const FILE_ATTRIBUTE_NORMAL As Long = &H80
Private Const METHOD_BUFFERED As Long = 0
Private Const FORMAT_MESSAGE_FROM_SYSTEM = &H1000
Private Const LANG_NEUTRAL = &H0

' Process Monitor Constants
Private Const FILE_DEVICE_PROCMON_LOG As Long = &H9535
Private Const PROCMON_DEBUGGER_HANDLER As String = "\\.\Global\ProcmonDebugLogger"
Private Const IOCTL_EXTERNAL_LOG_DEBUGOUT As Long = -1791655420

Dim hProcMon As LongPtr

Private Declare Function CreateFile Lib "kernel32" Alias "CreateFileW" _
(ByVal lpFileName As LongPtr, _
Optional ByVal dwDesiredAccess As Long = GENERIC_WRITE, _
Optional ByVal dwShareMode As Long = FILE_SHARE_WRITE, _
Optional lpSecurityAttributes As LongPtr = 0, _
Optional ByVal dwCreationDisposition As Long = OPEN_EXISTING, _
Optional ByVal dwFlagsAndAttributes As Long = FILE_ATTRIBUTE_NORMAL, _
Optional ByVal hTemplateFile As LongPtr = 0) As LongPtr

Private Declare Function DeviceIoControl Lib "kernel32" _
(ByVal hDevice As LongPtr, _
ByVal dwIoControlCode As Long, _
ByVal lpInBuffer As LongPtr, _
ByVal nInBufferSize As Long, _
Optional lpOutBuffer As LongPtr, _
Optional ByVal nOutBufferSize As Long, _
Optional lpBytesReturned As Long, _
Optional ByVal lpOverlapped As LongPtr) As Long

Pr

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&, Err.LastDllError, LANG_NEUTRAL, Buffer, 200, ByVal 0&
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 ;-)

StackExchange Code Review Q#97745, answer score: 7