Tracking down a BSOD Crash: AESTAud.sys

So a very unusual thing happened on my work system this past week.

It experienced a BSOD.

While that really isn’t a globally unusual thing for Windows users, for me, on my systems, that is pretty rare.

Not only was it rare, it was extraordinarily rare, as it was the second time it happened, out of nowhere, with the same root cause being reported..

Here’s how I dissected the bugger, now that it had captured my full attention.

The first time I experienced the BSOD was back on 06-24-10.  Stuff happens so I just rebooted and went on relatively unconcerned.

The next BSOD event was on 07-14-10.  This go-round I had much more time.

The system is a Dell Latitude E6400 laptop system, freshly issued and sporting a fresh image of XP Pro, SP3.

Once the system rebooted, I fired up Nir Sofer's BlueScreenView to get some quick details on the crash.

Not surprisingly, both of the crash events had been logged and BSV was able to report their details.  Surprisingly, both crashes involved the following element:

AESTAud.sys by the Andrea Electronics Corporation.  The file version was 2.0.0.3 / 32-bit flavor.  This is the Andrea Audio Driver

A round of Google work on that one indicated that it was a legit system driver.

I then fired up Autoruns for Windows and quickly found both the auto-loader for this driver under the HKLM\System\CurrentControlSet\Services

aestaud.sys, 111 K, Andrea Audio Driver, Time: 04/21/2009 10:13 PM, version 2.0.0.3 system32\drivers\AESTAud.sys

…as well as just one other Andrea-releated executable in the auto-run groups under the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

aestfltr.exe, 456 K, AEFltrs MFC Application, Time:05/20/2008 10:21 PM, version 4.5.10.0 %SystemRoot%\system32\AESTFltr.exe /NoDlg

More Google work on this executable also indicated it was legit.  And that curious “/NoDlg” argument appended to the executable seems to be a “no dialog / silent” manner of executing it, probably suppressing a windows launching dialog box.

So I unchecked them both in Autoruns to prevent them from loading.

I also consulted with Process Explorer to check what the (still running for now) AESTFltr.exe process was calling:

Process: AESTFltr.exe Pid: 5308

Name    Description    Company Name    Version
ADVAPI32.dll    Advanced Windows 32 Base API    Microsoft Corporation    5.1.2600.5755
AESTFltr.exe    AEFltrs MFC Application    Andrea Electronics Corporation    4.5.10.0
comctl32.dll    User Experience Controls Library    Microsoft Corporation    6.0.2900.5512
comctl32.dll    Common Controls Library    Microsoft Corporation    5.82.2900.5512
ctype.nls           
GDI32.dll    GDI Client DLL    Microsoft Corporation    5.1.2600.5698
IMM32.DLL    Windows XP IMM32 API Client DLL    Microsoft Corporation    5.1.2600.5512
kernel32.dll    Windows NT BASE API Client DLL    Microsoft Corporation    5.1.2600.5781
locale.nls           
MFC42.DLL    MFCDLL Shared Library - Retail Version    Microsoft Corporation    6.2.4131.0
MSCTF.dll    MSCTF Server DLL    Microsoft Corporation    5.1.2600.5512
msctfime.ime    Microsoft Text Frame Work Service IME    Microsoft Corporation    5.1.2600.5512
msvcrt.dll    Windows NT CRT DLL    Microsoft Corporation    7.0.2600.5512
ntdll.dll    NT Layer DLL    Microsoft Corporation    5.1.2600.5755
ole32.dll    Microsoft OLE for Windows    Microsoft Corporation    5.1.2600.5512
RPCRT4.dll    Remote Procedure Call Runtime    Microsoft Corporation    5.1.2600.5795
Secur32.dll    Security Support Provider Interface    Microsoft Corporation    5.1.2600.5834
SHELL32.dll    Windows Shell Common Dll    Microsoft Corporation    6.0.2900.5622
SHLWAPI.dll    Shell Light-weight Utility Library    Microsoft Corporation    6.0.2900.5912
sortkey.nls           
sorttbls.nls           
unicode.nls           
USER32.dll    Windows XP USER API Client DLL    Microsoft Corporation    5.1.2600.5512
uxtheme.dll    Microsoft UxTheme Library    Microsoft Corporation    6.0.2900.5512
VERSION.dll    Version Checking and File Installation Libraries    Microsoft Corporation    5.1.2600.5512
WINMM.dll    MCI API DLL    Microsoft Corporation    5.1.2600.5512

Then I rebooted and now got an error dialog box related to stacsv.exe. I was able to cancel that and all was well…except I didn’t have any audio now and all my control-panel options for the Audio were grayed out.

So I did some more searching for that file in Autoruns and located it under HKLM\System\CurrentControlSet\Services

stacsv.exe, 224 K, Manages audio jack, IDT, Inc. Time: 03/09/2010 11:56 PM, Version 1.0.6274.0 c:\program files\idt\wdm\stacsv.exe

Man, these things were all hooked together quite tightly!

I was hopeful that maybe the Andrea Electronics items were part of an “custom software” package to allow for enhanced sound control management on the system.  Unfortunately a deep search through the Add/Remove Programs (via Nir’s MyUninstaller utility) didn’t find any references to one.

I did find an InstallShield reference to IDT, Inc however.

And in searching on “stacsv.exe” on my system with Nir’s SearchMyFiles tool, I found it in the following locations:

C:\dell\drivers\R267815\WDM
C:\Program Files\IDT\WDM

Dropping to the IDT folder I found the setup.exe file, ran it (to see if a reload helped or maybe it would kick off an uninstall/repair option), the installer balked that the setup was not the right image for the system….and it promptly removed everything in there.

I guess that was progress.

Because I hadn’t logged the files in the IDT\WDM folder before running the setup file which removed them, I next mounted a WIM file I have of the stock system image and looked in the same location.  Lots of stuff in there this time (42 files).  I’ll save you the list, but there were unpacked driver sys files, CPL files, exe files, dll files for all kinds of both x32 and x64 supported systems, and….

…both the AESTAud.sys and AESTFltr.exe files were present and the commonality in the date-stamps seemed to be May-2008 for the most part.

So now I had two more bits of critical info; Andrea Electronics which appears to be supplying the audio driver controls for the IDT provided audio hardware, and that Dell clearly provides a driver package for this stuff known under the moniker “R227815”, and our images seemed to ship with hardware drivers back from 2008.

I next went into C:\dell\drivers\R267815\WDM location and re-ran the setup from that set. Again it complained that the setup was not the right image for the system.  Checking the C:\Program Files\IDT\WDM location again, found 44 files now in that location and that they were all from the March 2009 period.

Hmmm.

Still getting bad driver install errors…not sure why…better to to Dell to pull down a clean set.

I quickly found the R267815.exe –Dell Drivers and Downloads page, confirmed it was compatible with the E6400 Latitude system, and this one had a release date of 05/04/2010, version 5.10.0.6274,A11.  It is for the IDT 92HDxxx HD Audio hardware and “Fixes issue where line-in was selected as default recording device instead of microphone.”  Previous versions can be found at this Dell 92HDxxx HD Audio Support page, where both 2008 and a March 2009 release versions could be seen.

I downloaded the most current 05/2010 version and it did not complain this time when the setup installer was run.

Rebooted the system for good measure and the calls to the previously disabled items in AutoRuns were present and activated (note the disabled ones were still present, so I removed those duplicates), but now were reporting as follows:

aestfltr.exe, 720 K, AEFltrs MFC Application, Time:07/07/2009 2:06 AM, version 5.0.0.5 %SystemRoot%\system32\AESTFltr.exe /NoDlg

stacsv.exe and aestaud.sys remained unchanged.

I’m not sure why the previous IDT setup packages I found already present on the system failed due to an image compatibility problem.  However the last I downloaded directly from Dell did work and I can see evidence that some files related to the original BSOD party have now been updated to newer release versions.

To date, I’ve not had any additional BSOD issues, and will be hopeful whatever triggered both crashes has now been resolved with this last update.

Nor is it clear to me (I haven’t tried to do a debugging session on the original crash data yet) why audio-drivers were causing a system crash.

In the meantime, I will be watching closely and plan to clean up these older/cranky audio driver packages from our base image next time I build a refreshed system image.

Cheers!

--Claus V.