JeremyNicoll

BSOD on XP Pro system, possibly OADriver.sys implicated

Recommended Posts

My single-core XP system nearly hung last night, though I was out of the room when it happened.  The machine had been booted at about 2300 and I noticed it was nearly hung at about 2315.    It had become nearly totally unresponsive - once in a while a figure would update in task manager, or the taskbar clock display would change, but the taskbar clock got more and more behind reality.  When I dragged the task manager window to one side it did drag, but there was a delay of several minutes before the desktop re-drew underneath it.  I left the machine alone for quite a while as I was extrememly reluctant to power the machine off.  Eventually it BSODed; my notes say this happened at 0055 but the BSOD minidump time shows 0043, showing the clock lagging.  

 

Nir Sofer's BlueScreenView.exe suggests OADriver.sys might be the problem.  I used the OA 'submit' option to send the minidump to you a few hours ago.

 

Possibly related: around 2245 I found that a different (2-core) machine had had some sort of network problem - I found that Firefox suddenly wouldn't refresh or fetch any pages, but that machine still had a working network connection.  Stopping & restarting Firefox solved that.  In its event log I found a record that said that at about 2200 its TCP/IP had reached the maximum number of permitted concurrent connection attempts.  I've never seen that happen before.

 

If I remember rightly EAM was attempting a definitions download on the hung machine (the taskbar icon with the little down-pointing arrow was displayed though the arrow wasn't moving).  I did wonder if it and perhaps OA had a TCP/IP problem too.

 

Looking back in OA's log on the machine that hung, I see a series of 15 events like:

 

Created:      20/04/2013 23:23:58
Summary:      Program Guard: kernel event
Description:  OADriver: - 413 SignalAndWaitForAnswerEx - TIMEOUT. pid = 3964 tid = 2944
Event type:   Kernel event(26)
Event action: None(1)
Processes:

 

happening from 231457  until 005233.  There's nothing else recorded at that time.  I do realise that OA might be a victim, rather than the cause of the problem.
 

 

Share this post


Link to post
Share on other sites

Hi Jeremy,

 

I used the OA 'submit' option to send the minidump to you a few hours ago.

 

 

Did you save the submit-id somewhere? If you did, what is the submit-id?

If you didn't save it, could you please send the minidump to Emsisoft support with a link to this topic?


Could you please attach the minidump to your next reply?

Share this post


Link to post
Share on other sites

That's odd; although I recall seeing a poup telling me that OA was allowing access to your servers to send the file, I don't recall seeing a submit-id, which I would certainly have saved if I had seen it.  Is it something that would have been displayed until I dismissed/acknowledged it, or it there some way I could have missed it?   I also think the entry became unticked (and greyed?) in the list of dumps (there was only one) in the dump reporting dialogue.   I also don't see any way that I can repopen that dialog, which is perhaps a bad thing.

 

I'll send the dump to you in a PM.

Share this post


Link to post
Share on other sites

Jeremy.

I placed the minidump in the Windows minidump folder on my XP system and shutdown/restart OA.

 

 

The minidump is detected.
 


Submitted

 

Greyed, because this one is submitted.

 




I don't know why you didn't see the submit id info. The upload was performed in the blink of the eye, may be you accidentally clicked the close button?
 

Share this post


Link to post
Share on other sites

Please forgive me for jumping in so late, however minidumps don't normally contain enough information to debug BSoD's. For that we would need a full memory dump. We have an article at this link that explains how to set Windows to create a full memory dump when a BSoD happens. The full memory dump is usually saved as C:\MEMORY.DMP, so if you could get a full memory dump from the BSoD then that will help our developers to determine what caused the issue.

Share this post


Link to post
Share on other sites

OK, I made the changes in Control Panel - System...  (no need to install or run BellaVista for that).   So if it does BSOD again I'll be able to send you a URL to fetch a dump from.

Share this post


Link to post
Share on other sites

More info: I've got CompleteMemoryDump set on the machine I'm using most at the moment, a netbook.  My older laptop (which is the machine which had the BSOD I reported at the start of this thread) has become flakey (it hangs quite often if not BSODing) and I'll set it there next time I have it on, if I can.  I might also force a BSOD next time it hangs, if it's responsive enough to let me do that.

 

I also have a desktop machine with 3 GB RAM in it and I do not expect to be able to set it there.  It turns out that there's two problems; first when XP generates a BSOD dump it does so in two stages - placing data in the page file, then at the next boot creating the C:\MEMORY.DMP files from the stored data.  In XP, the page file used for this HAS TO BE on the same disk partition as the OS.  However on this desktop machine the page file's in a partition by itself on a separate drive.   Though... according to

 

  http://support.microsoft.com/kb/314482/en-us

    - How to configure paging files for optimization and recovery in Windows XP

 

the solution to this is to define several paging files.    The one on the system partition needs to be 1 MB greater in size than the
machine's RAM, so that the dumptask can write header info out before dumping storage.  Fortunately it seems that XP is intelligent enough (if there's more than one paging file defined) to use the one on the least-active partition to support virtual memory, and only use the on the system partition for dumping.   So I'd try that, if it wasn't for the next problem...

 

According to: http://support.microsoft.com/kb/307973  - which has lots of info about the registry entries that get set for various recovery options - "Complete Memory" dumps are not possible on 32-bit systems if the amount of RAM in use is 2 GB or more.  I'm reluctant to take RAM out of this machine, unless it starts BSODing so much that I can expect to recreate the problem easily.

 

Having said that, the netbook is being used every day, so if there's a OA/EAM problem causing BSODs that's where it's most lilely to show up.

Share this post


Link to post
Share on other sites

The RAM issue is probably due to the nature of Physical Address Extension in Windows XP.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.