Occasional Errors with Win 7 and IE8 and IE9 (SOLVED)

I am testing under different versions of Windows and IE. It makes no difference if compiled under XP SP3 or Win 7.

Running the EXE under;
Windows 2000 SP4, IE5: The EXE got an error immediately. I didn’t attempt any further. No support for 2000.

Windows XP SP3, IE8: The following problems do not occur at all with XP.

Windows 7 SP1, IE9: After the starting the EXE and right before the app displays the first window, an error occurs, The ordinal 459 could not be located in the dynamic link library urlmon.dll. This happens more frequently than having IE8 installed. The program seems to run fine regardless. After exiting, sometimes, an error occurs, Accessing violation at address 007C995F in module “Test_02.exe” feed of address 00000094.

Windows 7 SP1, IE8: The ordinal error only appears occasionally; however the Accessing violation at address 007C995F in module “Test_02.exe” feed of address 00000094 occurs about the same with IE9 installed. As with IE9, the program seems to run fine regardless.

Windows 8, IE 7: The program is automatically in IE 7 compatibility mode regardless of the setting. Which is fine since it is a preview copy. I have not seen the ordinal error but occasionally, on occasion at least three different memory addresses are displayed after exiting the program, only one or two at a time after exiting and sometimes no error messages at all. I am not concerned with Win 8 and it will be blocked until the final release version is available.

My goal, is to detect the Windows OS and IE version to either allow to run or not. My EXE has issues with IE6 and the program will ask the user to upgrade to least version 7.

There is nothing in the event logs to explain the errors or why they are happening.

HE 4.1.1 and the only setting toggled was the IE7 compatibilty mode which didn’t make any difference in the above results.

If you need any additional information, please contact me.

Thanks,

I’m not aware about these errors. It may be related to your project. Is it an advanced project or a basic sample?

Otherwise, could you please try to enable the “NoMultiThreading” property:



and see whether these access violation errors occur on your machine?

The project is really not that complex. With the NoMultiThreading, it seems to help with the startup error but not with the error on exiting.

After doing some researching, this is what I came up with so far. The following files don’t seem to be properly registered. On the other hand, using a program RegDllView from Nirsoft.com, it shows something a little different.

c:\windows\system32\regsvr32 c:\windows\system32\urlmon.dll
c:\windows\system32\regsvr32 c:\windows\system32\Shdocvw.dll
c:\windows\system32\regsvr32 c:\windows\system32\Actxprxy.dll
c:\windows\system32\regsvr32 c:\windows\system32\Oleaut32.dll
c:\windows\system32\regsvr32 c:\windows\system32\Mshtml.dll
c:\windows\system32\regsvr32 c:\windows\system32\Browseui.dll
c:\windows\system32\regsvr32 c:\windows\system32\Shell32.dll

Running the a batch with the commands above, the first and last ones passes and 5 in the middle fails. When using the program RegDllView, the top five shows registered as of the actual installation date and time. Browseui.dll does not show up as being registered and the last one, shell32.dll which passes, shows a registration date of 07/2009.

The above is from a brand new installation from last night. The batch failed before installing the VMtools. No other software or any of the updates were added.

If possible, if you have a test machine, could you create a batch of the seven lines and get the results to see if they pass or fail. All it does, is tries to re-register the files.

I will update this when I come across something new.

Thanks,

Quick update. I ran the batch file against a different machine and files, 3 and 4 were registered. Went and got the latest updates from MS and no difference when running the batch again. However the Mshtml.dll was updated this month. According to the RegDllView, the Mshtml.dll has a control point. I am assuming it should have registered.

Later,

Here is the latest update.

First of all, I might have failed to mention, that the error messages occured in Windows 7, not XP, both in a virtual and in a physical machine. When searching the registration of the files, many referenced that there was permission issues which didn’t help. Even trying to register the files with the System account, failed. This link referenced the below, http://answers.microsoft.com/en-us/...erserver/c6941f4d-159e-433b-a92f-9d3d0f9c6056

It would be nice to know what files can be registered and what cannot. But that is a different issue.

I will save you some time and frustration:

The mshtml.dll after Internet Explorer 6 has no entry point for registration.

Unless you are using Internet Explorer 6, those directions will not allow you to unregister or re-register the mshtml.dll file (try it).

Running the scan also will not help you.

Click to expand...

I use a Javascript syntax checker and it showed no errors. Then I went through all the source code with JSlint and cleaned up a lot of possible problem areas. The errors still occured randomly when exiting the EXE. Enabling the NoMultiThreading did not really help. It is disabled now.

I commented out some code and tried different things to isolate the problem. After commenting out the popups, the errors did not occur anymore. As a test, I replaced the popups with Javascript popups and the errors never surfaced again. Here is a sampling of one that was changed.

Old Code: src=“graphics/test1.png” border=0 alt=“Test Page 1”/>

New Code: src=“graphics/test1.png” border=0 alt=“Test Page 1”/>

function testwind(){
window.open(‘TestPage_1.htm’,‘test1’,‘scrollbars=yes’,‘width=600,height=400’,‘resizable=no’,‘toolbar=no’,‘location=no’,‘directories=no’,‘status=no’,‘menubar=no’,‘copyhistory=no’);
}

I have the skinning feature turned off and the windows appear to be identical.

I will update this if the errors come back but after pretty extensive testing, I think the issue is resolved.

Thanks,
HawkeyeTX

Thanks for the follow-up.