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:

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

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:

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.

3 comments:

That aesfltr.exe has always caused issued for me. Every single time I've recreated our images (usually do so every 2 years or so) and I decide to leave it alone it ends up causing issues and I end up going back and just deleting that executable. After that problem solved.

Credits

Why this? It is the simple blog of a Last Exile fan and is intended to express the enjoyment we derive from studio Gonzo's production. Although we closely relate with those characters, we aren't them in real life. We just want to keep the memory of these incredible young kids alive. So go buy Gonzo's Last Exile DVD's!