Missing IESHIMS.DLL & WER.DLL

[brutus1234]

Just installed my shiny new slipstreamed winxp sp3 in a virtual machine and wmp9 doesn't work! It complains it is not installed the right way.

I checked the executable via dependencywalker and I saw two dll are missing: IESHIMS.DLL and WER.DLL (screenshot attached).

I used winxp pro with sp3, adding ie8 and each and every hotfix and update suggested by Mimo, except for wmp11. You can see this in my hfslip.log.

What went wrong? Where can I get these libraries?

hfslip_1.zip

[Mim0]

I saw that you are using more files than listed in the XP-list. Can you make a test: Remove all files which are listed as "unknown" by the file-checker?

Mimo

[brutus1234]

Uh???

What a strange strategy: removing software packages in order to achieve more installed software?

[bphlpt]

Sometimes having extra stuff can confuse things during install so that things don't get installed correctly, Other times extra stuff can cause something to be installed that then replaces something else. Anyway, when there is a problem, it's always best to go back to a known working state then add things back in slowly till you find out what's screwing things up.

Cheers and Regards

[fdv]

Uh???

What a strange strategy: removing software packages in order to achieve more installed software?

Heh

Windows Error Reporting is not a dependency as such. Try this again with FILEMON and forget this dependency walker; it will mislead you. TRUST me on that one.

Run filemon, select filters, uncheck successes, click OK, and then relaunch MP9 and see what's actually failing. WER.DLL is not actually needed for MP9 to work. (Because MP9 works for me and my dozen systems and I don't have WER.DLL, before you ask). The IE shim is neither here nor there; it's a legacy for launching media within IE. And for God's sake get rid of all that extra DX9 stuff in cabs.

I examined the log but I don't see anything obvious, so try the FILEMON bit.

[brutus1234]

And for God's sake get rid of all that extra DX9 stuff in cabs.

Aren't they useful?

Are they too many?

[tommyp]

You really don't need the dx9 cabs unless you have an application that requires it. You'd know if your application needs the extra dx9's because it will prompt you to install it.

[brutus1234]

You really don't need the dx9 cabs unless you have an application that requires it. You'd know if your application needs the extra dx9's because it will prompt you to install it.

Well, I definitively do NOT need them!

BTW, can someone explain strange messages from hfslip during archive extraction (the first stage)?

Sometimes I can read "0 files extracted", why this? Does MS provide empty hotfixes?

Further, some file shows "access denied" but the folder was created by me, I'm sure I have full access to the files! Can't figure out this.

FIX: the strange messages are not from hfslip: they are localized, so they're coming from self-extractors.

Edited March 27, 2010 by brutus1234

[brutus1234]

I examined the log but I don't see anything obvious, so try the FILEMON bit.

Ok, filemon (hey, finding this tool isn't easy at all, anyway!) tells wmp can't find some components. The strange is:

1) these libraries are neither wer.dll nor ieshims.dll

2) missing libraries exist on the system! They are into windows\system32 but wmp can't find them.

[tommyp]

MSFT does release some hotfixes that are just registry updates. HOwever, there are some cases where MSFT releases a different type of hotfix that may not be supported by hfslip extraction. Those would get processed at t-13 via the hfsvcpack folders. More than most times, hfslip supports the critical updates, because, well they are critical. Optional hotfixes and suggested hotfixes/packages are sometimes packed differently. Usually optional hotfixes and suggested hotfixes are just extra stuff that msft wants you to have for some reason. The OS will still perform fine without them. There's two or three general types of users of hfslip. There's some that can't live life normally if they see anything at all reported by WU. At one point in time, there was a fatal flaw with WU where it reported a HF was not installed unless the OLD binary was present. There's other users that will just install the critical ones. Then there's the last batch that uses reduced source (i.e. fdvfiles and/or hfcleanup).

If in doubt with the zero files copied, I encourage you to verify that the hotfix isn't replaced by something else. If you see zero files extracted, I'd say that either you have either (a) a bad downloaded exe file, (B) something that isn't supported by hfslip, or © some hacked file that isn't packed to normal msft standards.

[brutus1234]

I examined the log but I don't see anything obvious, so try the FILEMON bit.

Ok, filemon (hey, finding this tool isn't easy at all, anyway!) tells wmp can't find some components. The strange is:

1) these libraries are neither wer.dll nor ieshims.dll

2) missing libraries exist on the system! They are into windows\system32 but wmp can't find them.

I can confirm this behaviour on my latest hfslip-streamed system also, this one is built with no extra/unknown/dx9 packages.

Wmp9 is the only executable showing this problem.

Edited March 28, 2010 by brutus1234

[tommyp]

Dumb q, but I must ask. Why use the outdated wmp9 and there are other and far better media players out there? I never had luck with wmp9 or wmp11 recoginizing mp3 id tags properly when every other media player saw them correctly. On a sidenote, if you have wmp9 installed, you can't view videos encoded with wmv11 codecs.

[brutus1234]

Dumb q, but I must ask.

Of course, this is a logical question.

I'm aware that wmp9 is outdated and it's actually not my favourite player. I play music via foobar2000 and videos via Media Player Classic or even MPlayer (using command line) but, since I always used nLite until yesterday, I want to be sure this break up is not related to some other system failure which may badly appear in the next days (after a real installation). Lacking wmp9 won't hurt, but system hanging will.

During my latest trial I was even able to watch some embedded wmv into IE8 so I'm quite sure the multimedia system is working and the crash of wmplayer.exe is taking less and less relevance.

[tommyp]

Maybe there is a requirement that IE8 needs WMP11? I can't say.

Obviously, you can just include WMP11 and not get the errors, or you can help diagnose things. Try this. Remove the following files from the HF folder. Let's try to isolate which hotfixes are giving a prob.

a - Q282784_WXP_SP1_x86_ENU.exe

b - WindowsMedia9-KB969878-x86-ITA.exe

c - WindowsXP-WindowsMedia-KB952069-v2-x86-ITA.exe

d - WindowsXP-WindowsMedia-KB954155-x86-ITA.exe

e - WindowsXP-WindowsMedia-KB968816-x86-ITA.exe

f - WindowsXP-WindowsMedia-KB973540-x86-ITA.exe

g - wmfdist95.exe

a - You probably saw extraction errors with this one. The filename of this one seems foreign to me.

b thru f are WMP related hotfixes.

g - codecs. They may not be required for WMP9, I haven't used that package in quite some time.

Here is an interesting link related to a similar issue. Maybe foobar is fubar?

http://www.techsupportforum.com/microsoft-support/internet-explorer-forum/359789-ie8-wont-use-wmp.html

If you run into probs, please include your hfslip.log so we can see what you are doing.

[brutus1234]

Well, well, well.

I removed the files tommyp suggested and now I'm finally able to run wmp9 with no flaw. Each component of my virtualized slipstreamed XP is working as expected (but, of course, latest windows media updates are missing).

So what's happened this time? Can you say which of those packages introduces the bug?

a - Q282784_WXP_SP1_x86_ENU.exe

This is a very old package providing an outdated version of qfecheck (I really thought I removed this some time ago). I actually don't know how to slipstream the latest qfecheck.exe (I think it's version 6.2.29.0) which is floating on internet.