Windows 8.1 (possible) LogMeIn bug causing 0x44 BSOD

Patrick

Have seen more than a dozen of these last few days (hamdrv.sys & 0x44). In the majority of cases I have seen it is from a current hamdrv,sys driver. Often has Kaspersky installed as well.
 
Thanks Ken, much appreciated.

I too thought it may have been a conflict with security software, but one user removed McAfee and the issue persisted. It might be a bug!
 
I found a way to get in contact with them (they have a ticket system which you need to register for, but it's free). I hope I'll hear from them soon!
 
If you had a Kernel Memory dump, you could possibly attempt to find the other drivers used in the Driver Stack, by dumping a few data structures, but it doesn't seem to work well in a Minidump. I started with _IO_STACK_LOCATION.
 
I have requested a user set up a kernel-dump configuration before removing LogMeIn Hamachi so we can do just that. Here's to hoping they do!
 
Code: 
2: kd> [COLOR=#008000]dt nt!_IRP ffffe00001784310[/COLOR]
   +0x000 Type             : 0n6
   +0x002 Size             : 0x118
   +0x004 AllocationProcessorNumber : 3
   +0x006 Reserved         : 0
   +0x008 MdlAddress       : 0xffffe000`00e9b750 _MDL
   +0x010 Flags            : 0x60900
   +0x018 AssociatedIrp    : <unnamed-tag>
   +0x020 ThreadListEntry  : _LIST_ENTRY [ 0xffffe000`05449500 - 0xffffe000`05d9ded8 ]
   +0x030 IoStatus         : _IO_STATUS_BLOCK
   +0x040 RequestorMode    : 1 ''
   +0x041 PendingReturned  : [COLOR=#ff0000]0x1[/COLOR] ''
   +0x042 StackCount       : 1 ''
   +0x043 CurrentLocation  : 3 ''
   +0x044 Cancel           : 0 ''
   +0x045 CancelIrql       : 0 ''
   +0x046 ApcEnvironment   : 0 ''
   +0x047 AllocationFlags  : 0x4 ''
   +0x048 UserIosb         : 0x00000000`013614a0 _IO_STATUS_BLOCK
   +0x050 UserEvent        : 0xffffe000`068493a0 _KEVENT
   +0x058 Overlay          : <unnamed-tag>
   +0x068 CancelRoutine    : 0xfffff800`0208888c     void  +0
   +0x070 UserBuffer       : (null) 
   +0x078 Tail             : <unnamed-tag>

I've noticed something with the IRP which was completed twice, it seems to have been marked Pending, rather than being completed with the call to IoCompleteRequest. The IoCompleteRequest routine does check this flag, and will wait for the IRP to be completed if the packet returns STATUS_PENDING.
 
Isn't IoCompleteRequest called to ask that an IRP be completed, and if 0x44 occurs, the packet has already been completed but another call is made anyway? If so, I suppose what's occurring is it's completed, but then called again because it's marked Pending as opposed to Completed? Sounds like a bug with the driver itself.
 
Yes, that is how I would interpret the situation, we've been lucky here since the potential driver has been identified but usually you never get any indication of the driver causing problems.
 
I read the thread that zigzag posted, and it seems that some users were complaining about the lack of response from the development and support team for LogMeIn.
 
zigzag3143 said:
I have made contact with them directly and will post if/when? there is any news.
Click to expand...

Great, thanks Ken.

x BlueRobot said:
I read the thread that zigzag posted, and it seems that some users were complaining about the lack of response from the development and support team for LogMeIn.
Click to expand...

There has been a bit of an outrage regarding customers of LogMeIn due to their recent switch from being free on Jan 21st of this year. I can only imagine they are unbelievably swamped, and with this to worry about, they have a lot going on and have taken a step back a bit.
 
I am back, and with a kernel!

First off, the call stack is interesting:

Code: 
7: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`031a9d48 fffff803`d802e6f2 : 00000000`00000044 fffffa80`0ea3f910 00000000`00000f7a 00000000`00000000 : nt!KeBugCheckEx
fffff880`031a9d50 fffff880`1a801f0a : 00000000`00000000 fffff880`1ca7ac00 fffffa80`0c7852c0 fffffa80`0c7852c0 : nt! ?? ::FNODOBFM::`string'+0xb318
fffff880`031a9e30 fffff880`1a803059 : fffffa80`0c7852c0 fffff880`031a9f00 fffff880`031a9f80 fffffa80`0000004a : [I][COLOR=#008000][B]Hamdrv+0x1f0a[/B][/COLOR][/I]
fffff880`031a9e80 fffff880`1a802a56 : fffff880`031aa680 fffffa80`00000001 fffffa80`09686b90 fffffa80`09686cf0 : [COLOR=#008000][I][B]Hamdrv+0x3059[/B][/I][/COLOR]
fffff880`031aa540 fffff880`01e7dcc9 : fffffa80`0b3f51a0 fffffa80`09686b90 00000000`00000000 00000000`00000000 : [COLOR=#008000][I][B]Hamdrv+0x2a56[/B][/I][/COLOR]
fffff880`031aa570 fffff880`01e7c166 : fffffa80`09686b90 00000000`00000000 fffffa80`0c4dd7f0 fffffa80`0c4dd7f0 : ndis!ndisMSendNBLToMiniport+0xc9
fffff880`031aa5f0 fffff880`02305230 : fffffa80`09686b90 00000000`00000001 fffffa80`09686b90 fffffa80`0c4dd7f0 : ndis!ndisFilterSendNetBufferLists+0xd6
fffff880`031aa630 fffff880`0230540f : 00000000`00000000 fffffa80`09686b90 00000000`00000000 fffffa80`0c4dd7f0 : wfplwfs!L2NdisFSendNetBufferLists+0x80
fffff880`031aa670 fffff880`01e7dd8d : 00000000`00000000 fffffa80`09686b90 00000000`00000000 00000000`00000000 : wfplwfs!LwfLowerSendNetBufferLists+0x9f
fffff880`031aa6e0 fffff803`d80cb9a6 : 00000000`00000202 fffff803`d877abb9 fffff880`04714970 00000000`000007ff : ndis!ndisDataPathExpandStackCallback+0x31
fffff880`031aa720 fffff803`d80ce405 : fffff880`01e7dd5c fffff880`031aa910 00000000`00000000 fffff803`d82a8a08 : nt!KeExpandKernelStackAndCalloutInternal+0xe6
fffff880`031aa820 fffff880`01e7c05f : fffff8a0`046587f0 fffff803`d828d409 00000000`00000001 fffff803`d828c200 : nt!KeExpandKernelStackAndCalloutEx+0x25
fffff880`031aa860 fffff880`01e7c166 : 00000000`00000000 fffffa80`094f5bf0 fffffa80`08ff9970 00000000`00000000 : ndis!ndisInvokeNextSendHandler+0x2de
fffff880`031aa970 fffff880`04796997 : fffffa80`09686b90 00000000`00000022 fffffa80`0c5aebf0 fffff880`031aaa39 : ndis!ndisFilterSendNetBufferLists+0xd6
fffff880`031aa9b0 fffff880`0479bbc5 : fffffa80`0e44950e fffffa80`0e449500 fffffa80`0000004a fffffa80`00000014 : [COLOR=#ff0000][I][B]bdfndisf6+0x3997[/B][/I][/COLOR]
fffff880`031aaaa0 fffff803`d80c4b77 : fffffa80`095061a0 00000000`0020b553 00000000`00000000 fffff880`0479b934 : [COLOR=#ff0000][I][B]bdfndisf6+0x8bc5[/B][/I][/COLOR]
fffff880`031aab10 fffff803`d80b42a1 : fffff803`d82a2110 fffffa80`0850a040 fffff803`d80c4b18 fffff803`d807fc00 : nt!IopProcessWorkItem+0x5f
fffff880`031aab80 fffff803`d8048fd9 : 9212ecd9`41a9baff 00000000`00000080 fffff803`d80b4160 fffffa80`0850a040 : nt!ExpWorkerThread+0x142
fffff880`031aac10 fffff803`d80fd7e6 : fffff880`009cb180 fffffa80`0850a040 fffff880`009d6f40 fffffa80`0849f740 : nt!PspSystemThreadStartup+0x59
fffff880`031aac60 00000000`00000000 : fffff880`031ab000 fffff880`031a5000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

Aside from the various Network Driver Interface Specification and Windows Filtering Platform routines, we can see two BitDefender Firewall calls. As we ascend up the stack, we of course eventually see our three LogMeIn Hamachi Virtual Miniport Driver calls, and then the bug check.

What's really interesting to me is that BitDefender's firewall turned up in the stack. Normally, if I saw this first as opposed to a minidump, I would assume that BitDefender's firewall was causing conflicts, but it has shown in various scenarios that the user would remove their security software and or firewall and the issue continued, or they didn't have any installed whatsoever to cause conflict in the first place.

So, was it called maybe for reasons other than potential conflict? Possibly just noting that it had to deal with BitDefender before beginning the Network Driver Interface Specification routines?

Also, there's definitely a trend in the packet being marked Pending as opposed to Completed:

Code: 
7: kd> dt nt!_IRP fffffa800ea3f910
   +0x000 Type             : 0n-12272
   +0x002 Size             : 0xc5a
   +0x004 AllocationProcessorNumber : 0xfa80
   +0x006 Reserved         : 0xffff
   +0x008 MdlAddress       : (null) 
   +0x010 Flags            : 0x60900
   +0x018 AssociatedIrp    : <unnamed-tag>
   +0x020 ThreadListEntry  : _LIST_ENTRY [ 0xfffffa80`0ea3f930 - 0xfffffa80`0ea3f930 ]
   +0x030 IoStatus         : _[COLOR=#ff0000][I][B]IO_STATUS_BLOCK[/B][/I][/COLOR]
   +0x040 RequestorMode    : 1 ''
   +0x041 PendingReturned  : [COLOR=#ff0000][I][B]0x1[/B][/I][/COLOR] ''
   +0x042 StackCount       : 1 ''
   +0x043 CurrentLocation  : 3 ''
   +0x044 Cancel           : 0 ''
   +0x045 CancelIrql       : 0 ''
   +0x046 ApcEnvironment   : 0 ''
   +0x047 AllocationFlags  : 0x4 ''
   +0x048 UserIosb         : 0x00000000`01b12c30 _IO_STATUS_BLOCK
   +0x050 UserEvent        : 0xfffffa80`09017860 _KEVENT
   +0x058 Overlay          : <unnamed-tag>
   +0x068 CancelRoutine    : 0xfffff880`1a80188c     void  +0
   +0x070 UserBuffer       : (null) 
   +0x078 Tail             : <unnamed-tag>

The IoStatus also consistently appears to be IO_STATUS_BLOCK, which the driver sets the IRP's I/O status block to indicate the final status of an I/O request before calling IoCompleteRequest for the IRP. An I/O status block serves two purposes:


  • It provides a higher-level driver's IoCompletion routine a way of determining whether the service worked when the IRP is completed.
  • It provides more information about why the service either worked or did not work.

As far as I know, this is the completion status, either STATUS_SUCCESS if the requested operation was completed successfully as you mentioned earlier, or an informational, warning, or error STATUS_XXX value. This is where I am stuck, I cannot find where the error, warning, etc, is?

Would you like me to PM you the kernel so you can poke around, Harry?
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top