Trend Micro - interfering with kernel32 calls?`

I've run across a situation where a customer is reporting odd behavior from his system.  The software running on his system uses the GetVolumeInformation in kernel32 to document the machine's current hard drive serial number.  Sometimes it gets the serial number and other times it doesn't.  The user can literally run the app and not get the number, exit, then run the app and get the number.  Odd, just odd.  I've run through the P/Invoke declaration and it seems right.  I'm wondering if Trend Micro is interfering but am having a hard time understanding if it is, how.  Can Trend Micro interfer with kernel32 API calls?

Any API can be interfered with, but why would they? More importantly, why would they have it "fail" only some times?

@Ion Todirel: Trend Micro is an AV product.

@wkempf: That is what my brain says too.  I probably wouldn't even consider it if I didn't have so many years experience seeing how trend micro in particular, other anti-virus to a lesser extent, has caused ... well just wierdness.

We created a separate app that calls the same API using the same P/Invoke and logged the results and had the user randomly run it whenever they felt like it.  It never failed.

I'm perplexed.

@Ion Todirel: Sorry about that.  What MasterPie said.  It is an anti-virus product.

Do you get an empty lpVolumeSerialNumber, when GetVolumeInformation returns true?

-Josh

@davewill: Does it also happen when the virusscanner is disabled?

@JoshRoss: yes

@ZippyV: haven't been able to determine that in this specific case.  customer is locked down by group policy.

The customer app that occasionally fails (and the test app that never failed) currently has the following (circa 2005) P/Invoke signature:

  Private Declare Function GetVolumeSerialNumber Lib "kernel32.dll" Alias "GetVolumeInformationA" (ByVal lpRootPathName As String, _
                     ByVal lpVolumeNameBuffer As String, _
                     ByVal nVolumeNameSize As Integer, _
                     ByRef lpVolumeSerialNumber As Long, _
                     ByVal lpMaximumComponentLength As Integer, _
                     ByVal lpFileSystemFlags As Integer, _
                     ByVal lpFileSystemNameBuffer As String, _
                     ByVal nFileSystemNameSize As Integer) As Long

After taking out my pencil sharpener and trying to come up with the perfect signature, we are changing to the following newer signature to see if that helps:

  <Runtime.InteropServices.DllImport("kernel32.dll", CharSet:=Runtime.InteropServices.CharSet.Unicode, ThrowOnUnmappableChar:=True, SetLastError:=True)> _
  Private Shared Function GetVolumeInformation( _
                                               ByVal lpRootPathName As System.String, _
                                               ByVal lpVolumeNameBuffer As System.Text.StringBuilder, _
                                               ByVal nVolumeNameSize As System.UInt32, _
                                               ByRef lpVolumeSerialNumber As System.UInt32, _
                                               ByRef lpMaximumComponentLength As System.UInt32, _
                                               ByRef lpFileSystemFlags As System.UInt32, _
                                               ByVal lpFileSystemNameBuffer As System.Text.StringBuilder, _
                                               ByVal nFileSystemNameSize As System.UInt32 _
                                               ) As <Runtime.InteropServices.MarshalAs(Runtime.InteropServices.UnmanagedType.Bool)> System.Boolean
  End Function

It isn't good to throw changes out just to see what sticks but the Trend Micro theory doesn't sound provable in this situation.  If you feel like something wouldn't be marshalled right with the first signature it won't hurt my circa 2005 feelings to tell me.  Same for the second signature.