explorer hangs up after entering folder with wave-files

[Hedge]

Uninstalled SyncToy.
Same **** on both PCs.

They were not connected when I tried it earlier.

 

[SquonkSC]

Uninstalled SyncToy.
Same **** on both PCs.

They were not connected when I tried it earlier.

Good, now we know for sure.

The folders are not set as offline folders are they?

Why not just rename the folders to hedgehog2 or hedgehog's audio, or whatever?
We could be looking for a solution for ever, but if changing the name solves it, what's the big deal?

Greetz

 

[wallyinnc]

Woodchuck?
Sorry, I couldn't resist....
HH, do you have a antivirus program running? I experienced similar problems and it turns out that Kasperski is doing something that causes a similar bahavior. I have to say it is not to a specific folder. But better to cover all basis

 

[SquonkSC]

Woodchuck?

..

 

[wallyinnc]

HH, one more thing to check: do you have ownership to that folder? There is no reason you shouldn't and changing names shouldn't alter that, but it is worth looking into

 

[H2SO4]

...
That's why changing the name will stop the sync.
That's why two files couldn't be moved.
They were locked by a process, and what else could it be than synctoy?
...

Good catch. I didn't spot the "locking" issue from the OP's own description of events:

"I tried moving all the WAVs of that folder into another folder.
2 wave-files remained in the old folder."

 

[subchild]

I have the exact same problem.

I have the same problem on Windows 7. I have a drive (on a mirror raid) which has a folder with about 1000 .wav files (most of them recorded from vinyl by me). Whenever I open this directory I see the Windows 7 green bar at the top indicating that explorer is processing or discovering contents, but it never completes. I've left it running for hours. During this time explorer.exe is at or near 100%, and occasionally sharing most of my CPU with dllhost.exe. I can't even play any of these audio files; can't move them. Nothing. I've tried moving a few files to a different folder on a different drive (while in XP - different drive) and the same thing happened. Even with just a handful of wav files.

I'm using Windows 7 (32 bit) installed on a 128GB SSD. I've tried moving the wav files to that drive as well, but run into the same issue. I disabled indexing of files, and don't have SyncToy (as far as I know). I'm using the latest version of NOD32 Anti Virus. Btw, if I try to access this folder using a different program, such as the Ableton Live music software, I can search, play, etc. without any problems. Its super fast.

I've tried repairing the W7 installation, and a few other suggestions found on the web but nothing worked. I'm basically ready to give up on Windows 7 and keep using my old XP installation. In XP the folder works fine.

Any ideas or suggestions as most welcome. Thanks.

 

[H2SO4]

Any ideas or suggestions as most welcome. Thanks.

OK, since the simple stuff turned out to be not so simple...

1) The next time Explorer/dllhost get into this state, fire up Task Manager (TM).
2) For both processes in turn, right-click, select "create dump file", note the full path to the memory dump file which'll pop up a few seconds later.
3) Zip up both dump files as tightly as possible.
4) Upload to say rapidshare.com and paste the link here.

Analysis of the dumps may show what the process is waiting for.

 

[SquonkSC]

One thing I just thought of.

Those wav files. Are they by any chance recorded at 32bit floating point?

Win7 native codecs don't know how to handle those.
When you try to burn them to CD you will also get a error, as you should because CD's are 16bit.

What I think is that Windows is trying to read and/or create thumbnails for the files,
but since it doesn't support 32bit wav's, it stalls.

Could you try if changing the view to "detailed list" instead of "thumbs",
make a difference?

Greetings

 

[subchild]

Thanks for the quick replies.

I don't have the machine in front of me, but I'll give try to get the process dump tonight.

While I do have 24bit .wav files on that PC, I don't believe any of the ones in the directory that's problematic are anything other than 16bit. But I did see some threads on the web about the folder view and I'm using exclusively (and always have) the detailed list view.

Thanks again.

 

[subchild]

I just created the dump file (its 245MBs) and opening it in WinDbg produces this output:


Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [X:\explorer.DMP]
User Mini Dump File with Full Memory: Only application data is available

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
Windows 7 Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed Oct 14 19:43:59.000 2009 (GMT-4)
System Uptime: 0 days 0:02:51.656
Process Uptime: 0 days 0:02:36.000
................................................................
................................................................
................................................
Loading unloaded module list
.......................
eax=00000000 ebx=00000000 ecx=744c465a edx=00000030 esi=021aef28 edi=00000000
eip=773f64f4 esp=0023f9c4 ebp=0023f9e0 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!KiFastSystemCallRet:
773f64f4 c3 ret

 

[H2SO4]

I just created the dump file (its 245MBs) and opening it in WinDbg produces this output:

It's a bit more complex because there's no crash. Hence, the starting point in debugger analysis is not as obvious.

If you zip up the dump file real tight and upload it to say rapidshare or somewhere similar, I'll try to take a look.

 

[subchild]

Here you go. Thanks again.
RapidShare: 1-CLICK Web hosting - Easy Filehosting

 

[H2SO4]

Here you go. Thanks again.
RapidShare: 1-CLICK Web hosting - Easy Filehosting

Short version: I think your problem is caused by a kernel-mode driver. Unfortunately, the Explorer dump doesn't "see" into that space, so it's not possible to tell which driver from this info alone. I'd suggest testing what happens when you boot into safe mode. The most likely culprit is the anti-virus, but that is just a guess at this stage. Safe mode testing would be useful.

==================================================

Longer version: The work is being done by threads 2 and 22:

User Mode Time
Thread Time
2:6b0 0 days 0:00:36.441
22:b10 0 days 0:00:36.301
32:e20 0 days 0:00:01.326
37:dc0 0 days 0:00:00.686
0:668 0 days 0:00:00.483
5:6c0 0 days 0:00:00.202
10:7e0 0 days 0:00:00.140
...

At the point the dump was triggered, T2 has gone off into kernel-mode for its "ReadFile" command to be fulfilled:

ChildEBP RetAddr
01c6ecac 773f570c ntdll!KiFastSystemCallRet
01c6ecb0 7569abad ntdll!ZwReadFile+0xc
01c6ed14 75c3dafd KERNELBASE!ReadFile+0x118
01c6ed5c 75d1e08a kernel32!ReadFileImplementation+0xf0
01c6ed9c 69d1be11 shlwapi!CFileStream::Read+0xec
01c6edf4 69d1bf56 mf!CMFWAVPropertyHandler::FeedNextBufferToPlugin+0x8f
01c6ee74 69d1c06a mf!CMFWAVPropertyHandler::FeedBuffersToPlugin+0x63
01c6eea0 69b81458 mf!CMFWAVPropertyHandler::InternalInitialize+0x86
01c6eeb8 76763eb1 mf!CMFPropHandlerBase<CMFWAVPropertyHandler,&CLSID_MFWAVPropertyHandler>::Initialize+0x5e
01c6ef10 76763cc3 shell32!InitializeFileHandlerWithStream+0x117

T22 is doing similar work but it's in user-mode:

ChildEBP RetAddr
038fee2c 69ddf1d3 mf!CRIFFChunkEnumerator::GoToChunkUsingAbsolutePosition+0x24
038fee40 69ddf338 mf!CRIFFChunkEnumerator::GoToChunkUsingRelativePosition+0x29
038fee6c 69ddf391 mf!CRIFFChunkEnumerator:arseRIFFHeader+0x110
038fee8c 69ddf40b mf!CRIFFChunkEnumerator::CRIFFChunkEnumerator+0x52
038feeac 69ddf47a mf!CLISTChunkEnumerator::CLISTChunkEnumerator+0x1f
038feed4 69d0e3c7 mf!CRIFFChunkEnumerator::EnumerateChunksInLISTChunk+0x40
038feef0 69d0e79e mf!CWAVFileParser:arseNextChunkForMetadata+0x3d
038fef08 69d0dfab mf!CWAVFileParser:arseHeader+0x11f
038fef1c 69d1be69 mf!CWAVMediaSourcePlugin:arseHeader+0x37
038fef84 69d1bf56 mf!CMFWAVPropertyHandler::FeedNextBufferToPlugin+0xe7

Given they've each consumed over 36 seconds of processor time so far - a huge amount - it's relatively safe to assume that they've got problems. The likely obstacle is down in kernel-mode: a driver.

Personally, the first thing I'd do is to test what happens with the AV temporarily uninstalled ("disabling" it is not a valid test).

 

[subchild]

Many thanks. Will give that a try.

 

[subchild]

I just installed a clean version of Windows 7 and tried to access the same directory before installing Anti Virus or any other apps. Same exact result. I'll post that dump tomorrow but I expect we'll see the same info in it.

I'm trying to update the SATA drivers now. Will also try logging into Safe Mode and seeing if that makes a difference.

 

[subchild]

Safe mode made no difference.

 

[H2SO4]

Safe mode made no difference.

Bu##er. I can't see any obvious interference from 3rd-party code in your Explorer process, and the fresh/clean install would seem to rule out an errant 3rd-party driver. If you're quite sure the new install is entirely devoid of non-default codec packs or anything of the sort, then it may indeed be a *cough* bug in Win7.

Try actually deactivating your sound card in Device Manager and then testing Explorer behaviour again. If you're using a non-default soundcard driver perhaps it's misbehaving.

Also, does it make a difference whether you've got explorer set to treat that folder as "media" or whether it's just straight "files"? I don't think I'm explaining that well but I don't know the proper terminology. Right-click the folder, properties, "Customize" tab, "Optimize this folder for:" - does it make a difference whether that's set to "music" or "general items"?

 

[subchild]

I don't have the sound card driver installed yet, but I'll try changing the folder properties. I also don't think that sata drivers matter as I'm experiencing the same behavior on the internal sata drives AND on the external sata drive which uses a SIIG pci card.

I do like everything else about Windows 7, but this issue makes it impossible for me to use it. I'm going back to XP.

 

[subchild]

One other bit of info that might be helpful.

The hard drives that the problematic folder resides on are all Seagate Barracudas. The most recent one was purchased earlier this year, but I haven't updated the firmware on any of them. Are there any known issues with W7 and Seagate drives (I think the model is ST350320AS)?

I'm going to try one last thing tonight - I've moved that folder to a Western Digital SATA drive. I'll see if the problem persists.