Author Topic: IE 7 beta 2 breaks WinMX (Read 7392 times)

theofour · « **on:** February 16, 2006, 08:44:25 pm »

After installing IE 7 beta 2 WinMX stopped working. After allowing WinMX to use ipconfig, it crashes (and wants to report to page that does not exist).

theofour · « **Reply #1 on:** February 16, 2006, 08:50:16 pm »

Quote from: theofour

After installing IE 7 beta 2 WinMx stopped working. After allowing WinMx to use ipconfig, it crashes (and wants to report to page that does not exist).

Well, the point of my post was to:
a) request fix/workaround
b) request crash reporting to be set updated to a new page (ie. crash reporting i this forum).

Bearded Blunder · « **Reply #2 on:** February 16, 2006, 08:55:04 pm »

Yes there is a problem with IE 7.. which if you read around the forum you'd know already. The problem may very well be with IE 7 itself, microsoft programs often get released with bugs & IE & is still in beta... you do use beta software at your own risk.......

KM · « **Reply #3 on:** February 17, 2006, 06:54:29 am »

IE7 doesn't like the 3.54 version of the patch. if you reinstall the patch then it will detect IE7 and suggest using 3.53 instead.

theofour · « **Reply #4 on:** February 22, 2006, 09:50:08 pm »

Yes, I understand that this is a common problem. However, I would not like to revert to old version of WinMX as I really like the new versions features.

Now I researched the problem further and found out that the exception occurs at:
"Unhandled exception at 0x77c47c7e in WinMX.exe: 0xC0000005: Access violation reading location 0x00000000." - in other words WinMX uses null pointer somewhere. There is no way IE7 can be blamed for that as null pointers are well known pitfall and therefore a must to avoid.

I also noticed that WinMX accessed IE7 feed .dat files before crashing. It makes me wondering, why does WinMX access these (and some other .dat files) at all? Also is there any way to get hands on the source of WinMX for further debugging? It is written in C++, isn't it?

theofour · « **Reply #5 on:** February 22, 2006, 09:57:28 pm »

Because my account here is probably expired, I'll add my e-mail here as well: siim04@ut.ee.

KM · « **Reply #6 on:** February 23, 2006, 07:27:33 pm »

it'd not winmx itself crashing, it is IE7 itself, the update bar thing in the top left is actually an IE window, when any program runs it looks for its dlls in the same directory that the program is running from, followed by looking in the system - that is how winmx loads the patches ws2_32.dll instead of the systems one, unfortunately IE also runs from the same place and also loads the replacement ws2_32.dll instead of the system one - unfortunately there is some small difference between the 2 (that i cant see...) that causes IE7 to crash

nylly444 · « **Reply #7 on:** February 23, 2006, 11:04:27 pm »

So theoretically it should work when you copy the system dll into the IE folder then?

KM · « **Reply #8 on:** February 24, 2006, 05:10:54 am »

nope, because IE runs inside winmx, so the working directory is that of winmx, thought of that one

nylly444 · « **Reply #9 on:** February 24, 2006, 12:05:57 pm »

Darn, why can't things ever be simple? :roll:

theofour · « **Reply #10 on:** February 25, 2006, 04:02:08 pm »

I did take a look at replacement DLL and original DLL. One of the most important differences I could notice was that original "delay-loads" (loads dynamically) SHLWAPI.DLL, while replacement loads it always. Also SHLWAPI.DLL does not resolve one dependency from URLMON.DLL. That could be the cause for IE crash with the replacement DLL as in case of replacement DLL as all SHLWAPI.DLL parent imports need to be resolved, while original does not require resolving all. SHLWAPI.DLL is being loaded by SHELL32.DLL.

Also User32.dll gets loaded dynamically in the original and all SHELL32.DLL functions are used indirectly in original (causing SHELL32.dll to be loaded dynamically).

My suggestion is to make shell32.dll dynamically loadable. Shell32.dll is being loaded for ShellExecuteA function. Depends (dependency walker) can be of use while debugging it

.

theofour · « **Reply #11 on:** February 27, 2006, 10:46:49 pm »

Apimon (one of Windows XP Support tools) turned out to be useful. I got the following stack trace (on crash):

Code: [Select]

0abcfc70 771b71cc strstr
0abcffac 771d5259 0x771b71cc
0abcffb4 7c80b50b 0x771d5259
0abcffec 00000000 GetModuleFileNameA

bughunter · « **Reply #12 on:** February 28, 2006, 02:09:33 am »

ponders why ppl would want to use a crappy beta in the first place..........
beta,s are always buggy and not worth a tin of shit at the best of times.........
hence why there are always warnings when downloading any beta software..........
the devolpers accept no responsibility if it crashes your pc or causes and lose of information.............
so best advice to fix that problem is dont download and run crappy beta,s instead run known good reliable software...........
in this case ie 6 and your problem will instantly dissappear.............
and that wil save km wasting his time trying to fix microsofts buggy internet explorer, which isnt his problem anyways...............

KM · « **Reply #13 on:** February 28, 2006, 07:39:14 am »

indeed, however once they decide to release IE7, it will be a problem... so not an immediate concern but i would prefer to have it work on as many systems as possible - having said that i won't be putting too much effort in to looking at the problems with IE7...

btw, a completely blank ws2_32.dll from my template that contains nothing but simply dynamically loading the original ws2_32.dll and mapping the functions to it causes a crash with IE7 as well, so i'm guessing it's an undocumented behaviour in the way winsock works that IE uses rather than something obvious

theofour · « **Reply #14 on:** February 28, 2006, 08:07:12 pm »

I have lots of programs using Internet Explorer windows or other components. No other but WinMX has any problems with IE7.

Are you suggesting that ws2_32.dll is causing the access violation not WinMX itself? That would be a very bad practice on MS side to allow libraries to cause (uncatched) exceptions. It is even worse not to check for null pointers (as it seems to be the case)!

By the way, is WinMX protocol open (public)?

bughunter · « **Reply #15 on:** March 01, 2006, 05:36:19 am »

since when have microsoft made any software that isnt full of holes code violations and other coding errors that require massive patching on almost a daily basis, the situation has gotten so bad that microsoft only release patches monthly now.
yous assertion that it is the dll causing the error has a problem in that i dl ie7 onto a test machine i have and it works fine,which would susgest its something more to do with your individual setup rather then a universal problem....
since you seem to have a idea about coding fix the problem your self......
like pie patch the dll works for tens of thousands of users everyday without problem......but there will always be certain ppl who have setups that cause a problem......even pie patch which after all is only a alteration of the hosts file doesnt work for some users which is truely bizzare....but thats life...../
if you want to insist on running microsofts test browser and it causes a issue then dont use the dll as a patch......make your own hosts file and be done with it.....
and as im sure you know microsofts final releases of any software very rarely is the same as the betas that preceeded it.....thats why there a beta fulll of bugs that they want the public to help fix......as km rightly pointed out he would like it to work but isnt going to put alot of energy into making a beta work as 9 times out of 10 the final release of ie 7 will be totally different to the beta.....so from his point of view its better to wait for the official release and sort any problems then to have to reinvent the wheel..........

KM · « **Reply #16 on:** March 01, 2006, 07:25:32 am »

IE makes a call to a system function, then that call is intercepted by the patch which behaves differently to how the system would normally deal with it, that difference then causes an error

it's not just some plugin loaded in to IE that IE has control over, as far as IE is concerned the functions it is calling are part of the operating system not part of some patch, so it expects it to be handled by the operating system... not really IE's fault, however some things about winsock could be better documented to avoid problems like this when patches have to work in this way

~~Josh~~ · « **Reply #17 on:** March 02, 2006, 12:04:27 am »

i dont see why anyone would want to use IE in the 1st place. Firefox or Opera are much better.

KM · « **Reply #18 on:** March 02, 2006, 07:39:40 am »

nobody mentioned using other browsers, as the fact that you open firefox to visit this website is completely irrelevant and doesn't change the fact that you use IE in winmx, and no other browser will ever be used by winmx except IE, install as many browsers as you want and you won't achieve anything