• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
PlanoTechs

Blue screen on new fleet laptop

12 posts in this topic

We recently installed a new laptop (Getac V110) in one of our fleet vehicles. I have gotten reports that users are getting a blue screen anywhere between 2 and 4 times in a 12-hour shift. I got a memory dump from the machine, but I don't have the resources to personally troubleshoot it. I wondered if I could get some assistance from the experts on this forum, as y'all have been very helpful for me in the past.

 

The memory dump can be found here: https://onedrive.live.com/redir?resid=AF7B9F3BAAA41FB7%21160

 

Thanks in advance for any help you can provide,

 

Justin

0

Share this post


Link to post
Share on other sites

The process that crashed was Microsoft MapPoint. What version of MapPoint is it?

The dump indicates a memory error, but I wonder if the other dumps are the same error or different ones. Even if you don't have the old memory.dmps, the bugchecks still may be preserved in Event Viewer.

It also looks to be you have a very old F-Secure encryption software installed, the driver it uses is from 2002.

0

Share this post


Link to post
Share on other sites

I just thought I'd add a little bit.

BAD_POOL_HEADER (19)The pool is already corrupt at the time of the current request.This may or may not be due to the caller.The internal pool links must be walked to figure out a possible cause ofthe problem, and then special pool applied to the suspect tags or the driververifier to a suspect driver.Arguments:Arg1: 00000020, a pool block header size is corrupt.Arg2: c42da2e8, The pool entry we were looking for within the page.Arg3: c42da468, The next pool entry.Arg4: 1830000b, (reserved)

So here we can see the pool entry we were looking for within the pool page and the next pool entry that should use this current pool.

0: kd> !pool c42da2e8Pool page c42da2e8 region is Nonpaged pool c42da000 size:   b8 previous size:    0  (Allocated)  File (Protected) c42da0b8 size:    8 previous size:   b8  (Free)       .... c42da0c0 size:   68 previous size:    8  (Allocated)  FMsl c42da128 size:  168 previous size:   68  (Allocated)  CcSc c42da290 size:   58 previous size:  168  (Allocated)  SAds*c42da2e8 size:  180 previous size:   58  (Free ) *Io   Process: 8bedc030		Pooltag Io   : general IO allocations, Binary : nt!ioc42da468 doesn't look like a valid small pool allocation, checking to seeif the entire page is actually part of a large page allocation...c42da468 is not a valid large pool allocation, checking large session pool...c42da468 is not valid pool. Checking for freed (or corrupt) poolBad previous allocation size @c42da468, last size was 30****** An error (or corruption) in the pool was detected;*** Attempting to diagnose the problem.****** Use !poolval c42da000 for more details.Pool page [ c42da000 ] is __inVALID.Analyzing linked list...[ c42da2e8 --> c42da5c8 (size = 0x2e0 bytes)]: Corrupt regionScanning for single bit errors...None found

Here we can see the linked list for the pool is corrupt, but the end of the list is with the next pool entry.

That is wrong, remember if we look back the next list entry should be c42da468 not c42da5c8 the cause is probably due to a driver overwriting the pool block.

0: kd> dt nt!_POOL_HEADER c42da2e8   +0x000 PreviousSize     : 0y000001011 (0xb)   +0x000 PoolIndex        : 0y0000000 (0)   +0x002 BlockSize        : 0y000110000 (0x30)   +0x002 PoolType         : 0y0001100 (0xc)   +0x000 Ulong1           : 0x1830000b   +0x004 PoolTag          : 0x20206f49   +0x004 AllocatorBackTraceIndex : 0x6f49   +0x006 PoolTagHash      : 0x2020

This is the pool allocation information which we were looking at.

0: kd> dt nt!_POOL_HEADER c42da468   +0x000 PreviousSize     : 0y101010000 (0x150)   +0x000 PoolIndex        : 0y0100011 (0x23)   +0x002 BlockSize        : 0y101010011 (0x153)   +0x002 PoolType         : 0y0100000 (0x20)   +0x000 Ulong1           : 0x41534750   +0x004 PoolTag          : 0x332c412c   +0x004 AllocatorBackTraceIndex : 0x412c   +0x006 PoolTagHash      : 0x332c

This pool is clearly corrupt as it's header has been overwritten.

 

A full memory dump would be needed to see what is being ran in user mode but MapPoint isn't necessarily the cause just because it's in the stack.

1

Share this post


Link to post
Share on other sites

Ah sorry about that, I forgot about asking him to enable Driver Verifier.

 

What is Driver Verifier?

Driver Verifier monitors Windows kernel-mode drivers, graphics drivers, and even 3rd party drivers to detect illegal function calls or actions that might corrupt the system. Driver Verifier can subject the Windows drivers to a variety of stresses and tests to find improper behavior.

Essentially, if there's a 3rd party driver believed to be causing the issues at hand, enabling Driver Verifier will help us see which specific driver is causing the problem.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"

How to enable Driver Verifier:

Start > type "verifier" without the quotes > Select the following options -

1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8/8.1)
- DDI compliance checking (Windows 8/8.1)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

- If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled per my instructions above, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.

- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > Search > type "cmd" without the quotes.

- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
 Restart and boot into normal Windows.

If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > type "system restore" without the quotes.

- Choose the restore point you created earlier.

-- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1

How long should I keep Driver Verifier enabled for?

I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.

My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?

- If you have the system set to generate Small Memory Dumps, they will be located in %systemroot%\Minidump.

- If you have the system set to generate Kernel-Memory Dumps, it will be located in %systemroot% and labeled MEMORY.DMP.

0

Share this post


Link to post
Share on other sites

Thanks very much, everyone. I'll get to work on Driver Verifier and see what I can find out.

1

Share this post


Link to post
Share on other sites

Okay, so I started the Driver Verifier, and then the vehicle got driven during a couple of 12 hour shifts. It looks like the system crashed sometime on the 12th, so I grabbed the memory dump and the minidump and then disabled Driver Verifier.

 

I have uploaded the dumps here: https://onedrive.live.com/redir?resid=AF7B9F3BAAA41FB7%21114

 

Thanks again, everyone.

0

Share this post


Link to post
Share on other sites

update the driver vsergps.sys (looks like a Modem or a different driver for a device with uses the COM port)

********************************************************************************                                                                             **                        Bugcheck Analysis                                    **                                                                             ********************************************************************************PAGE_FAULT_BEYOND_END_OF_ALLOCATION (cd)N bytes of memory was allocated and more than N bytes are being referenced.This cannot be protected by try-except.When possible, the guilty driver's name (Unicode string) is printed onthe bugcheck screen and saved in KiBugCheckDriver.Arguments:Arg1: a0e55000, memory referencedArg2: 00000000, value 0 = read operation, 1 = write operationArg3: 8303b2a0, if non-zero, the address which referenced memory.Arg4: 00000000, Mm internal code.Debugging Details:------------------DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULTBUGCHECK_STR:  0xCDPROCESS_NAME:  MapPoint.exeCURRENT_IRQL:  0TRAP_FRAME:  e005f80c -- (.trap 0xffffffffe005f80c)ErrCode = 00000000STACK_TEXT:  nt!MmAccessFaultnt!KiTrap0Ent!memmoveWARNING: Stack unwind information not available. Following frames may be wrong.vsergpsvsergpsnt!IovCallDrivernt!IofCallDriverserenum!Serenum_DispatchPassThroughserenum!Serenum_CreateClosent!IovCallDrivernt!IofCallDrivernt!IopParseDevicent!ObpLookupObjectNament!ObOpenObjectByNament!IopCreateFilent!NtCreateFilent!KiSystemServicePostCall0x0IMAGE_NAME:  vsergps.sysFAILURE_BUCKET_ID:  0xCD_VRF_vsergps+331cFAILURE_ID_HASH_STRING:  km:0xcd_vrf_vsergps+331c    Image path: \SystemRoot\system32\DRIVERS\vsergps.sys    Image name: vsergps.sys    Timestamp:        Wed Jul 29 12:37:36 2009
Edited by MagicAndre1981
0

Share this post


Link to post
Share on other sites
BugCheck CD, {a0e55000, 0, 8303b2a0, 0}

This bugcheck indicates a driver allocated a specific number of memory but referenced more bytes thna was allocated.

0: kd> .trap 0xffffffffe005f80cErrCode = 00000000eax=51510031 ebx=00000014 ecx=00000005 edx=00000000 esi=a0e54ff8 edi=d10f5008eip=8303b2a0 esp=e005f880 ebp=e005f888 iopl=0         nv up ei ng nz ac po cycs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010293nt!memmove+0x120:8303b2a0 8b448ef4        mov     eax,dword ptr [esi+ecx*4-0Ch] ds:0023:a0e55000=????????

We can see a move operation taking place, a dword value stored in the eax register was being moved to a memory location calculated by adding the esi and ecx registers, then multiplying it by 4. This results in memory write to a0e55000 which is more bytes than allocated.

0: kd> !pte a0e55000                    VA a0e55000PDE at C0602838            PTE at C05072A8contains 0000000073825863  contains 0000000200000000pfn 73825     ---DA--KWEV  not valid                            PageFile:  0                            Offset: 2                            Protect: 0

Here we can see the address was invalid, this is because it wasn't present in memory was it wasn't allocated.

0: kd> dc a0e55000a0e55000  ???????? ???????? ???????? ????????  ????????????????a0e55010  ???????? ???????? ???????? ????????  ????????????????a0e55020  ???????? ???????? ???????? ????????  ????????????????a0e55030  ???????? ???????? ???????? ????????  ????????????????a0e55040  ???????? ???????? ???????? ????????  ????????????????a0e55050  ???????? ???????? ???????? ????????  ????????????????a0e55060  ???????? ???????? ???????? ????????  ????????????????a0e55070  ???????? ???????? ???????? ????????  ????????????????

Yep, no memory addresses present.

e005f7f4 83042aa8 00000000 a0e55000 00000000 nt!MmAccessFault+0x104e005f7f4 8303b2a0 00000000 a0e55000 00000000 nt!KiTrap0E+0xdce005f888 b23ee31c d10f5008 a0e54ff8 00000014 nt!memmove+0x120WARNING: Stack unwind information not available. Following frames may be wrong.e005f8b4 b23f1f49 b3100898 a0e54ff8 a4d60e30 vsergps+0x331ce005f8dc 833336c3 b31007e0 00000000 b30fe3e0 vsergps+0x6f49e005f900 83038bd5 00000000 82aa0008 b31007e0 nt!IovCallDriver+0x258e005f914 b2d7c61f e9a1f378 00000000 82aa0008 nt!IofCallDriver+0x1be005f928 b2d7c6e7 00000000 01aa0008 82aa0008 serenum!Serenum_DispatchPassThrough+0x65e005f950 833336c3 b30fe328 b31007e0 d33154f8 serenum!Serenum_CreateClose+0xa5e005f974 83038bd5 00000000 d3315554 b30fe328 nt!IovCallDriver+0x258e005f988 83248516 cab224b1 e005fb30 00000000 nt!IofCallDriver+0x1be005fa60 83227d2e b31007e0 a5df8378 bf5c6d20 nt!IopParseDevice+0xee6e005fadc 83238157 00000000 e005fb30 00000040 nt!ObpLookupObjectName+0x4fae005fb38 8322ec35 001eebc0 85df8378 83042a01 nt!ObOpenObjectByName+0x165e005fbb4 832524b4 001eec1c 80100080 001eebc0 nt!IopCreateFile+0x673e005fc00 8303f8c6 001eec1c 80100080 001eebc0 nt!NtCreateFile+0x34e005fc00 775a70f4 001eec1c 80100080 001eebc0 nt!KiSystemServicePostCall001eec24 00000000 00000000 00000000 00000000 0x775a70f4

vsergps.sys may not actually be the cause but it's likely.

0: kd> lm vm vsergpsstart    end        module nameb23eb000 b2400000   vsergps    (no symbols)               Loaded symbol image file: vsergps.sys    Image path: \SystemRoot\system32\DRIVERS\vsergps.sys    Image name: vsergps.sys    Timestamp:        Wed Jul 29 11:37:36 2009 (4A702670)    CheckSum:         00020B18    ImageSize:        00015000    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

I'm struggling to find anything on the driver apart from the timestamp, there's absolutely nothing coming up from google regarding this.

If you know what it is then update that software, can you also tell us the program name.

0

Share this post


Link to post
Share on other sites

Looks like vsergps.sys is part of the Mitac Virtual GPS System. File version 2.0.0.1.

 

I could not, however, find any information on the Mitac website or on the websites of any of the brands they own (Magellan, Mio, or Navman) about this Virtual GPS software.

 

I spoke to Getac (the brand of computer I'm dealing with), and it appears that they've rebranded the Virtual GPS software as their own. It's a virtual port splitter and allows multiple virtual ports to use the GPS signal coming through the physical port. MapPoint was using it because it was pointing to one of the virtual COM ports for its GPS signal.

 

I uninstalled the software, deleted the driver, and removed the "Multi-Serial Port" from Device Manager. This should resolve the problem.

 

Again, I couldn't have done this without y'all's help. I greatly appreciate your expertise.

Edited by PlanoTechs
0

Share this post


Link to post
Share on other sites

Okay, any other problems don't hesitate to post back.

0

Share this post


Link to post
Share on other sites

 

I spoke to Getac (the brand of computer I'm dealing with), and it appears that they've rebranded the Virtual GPS software as their own. It's a virtual port splitter and allows multiple virtual ports to use the GPS signal coming through the physical port. MapPoint was using it because it was pointing to one of the virtual COM ports for its GPS signal.

 

I uninstalled the software, deleted the driver, and removed the "Multi-Serial Port" from Device Manager. This should resolve the problem.

 

 

thanks for the information, so my guess of the COM port was correct. Nice to hear that you fixed it :)

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.