Install Issue

[hto]

I assume that was directed at a poster whose post no longer appears here?

Yes, there was a post with spam links.

[FlyingIsFun1217]

The E5300 you have, does it support VT-x? It seems some of that model do, but not all of them, and it seems like this might be an issue involving that (although I could be wrong).

FlyingIsFun1217

[milon]

I got the Intel Processor Identification Utility (go to http://ark.intel.com/VTList.aspx and click on Download Center). According to it, yes, my processor supports Intel Virtualization Technology. I assume that's VT-x although it wouldn't just come out and say so. Let me know if you want any other processor spec info.

[FlyingIsFun1217]

Once my big school projects are done, I'll see if I can't find a computer with virtualization that I can test the builds on. Otherwise, if someone else wants to try it (and maybe check if it's still an issue in recent release bootcd builds), that'd be awesome.

FlyingIsFun1217

[MadWolf]

hi
if you can install windows on that hardwhere then have a look at this http://www.grc.com/securable.htm

SecurAble probes the system's processor to determine the presence, absence and operational status of three modern processor features:

64-bit instruction extensions,
Hardware support for detecting and preventing
the execution of code in program data areas, ... and
Hardware support for system resource “virtualization.”

[milon]

I recently noticed that VirtualBox lets you turn VT-x on/off. So I turned it off, and tested an install with build 54658. It formatted the disk fine, but BSOD'd after 1st reboot (don't know when - it was minimized at the time). I rebooted and got partway through the Setup Wizard. It got to the part where it was copying/registering dll's. The progress bar got halfway, then it closed and I had a blank "desktop" with just the mouse. I think it was right at/after the mshtml.dll part (512MB ram, which seems to get around that problem) and right before the Wine Gecko Installer bit shows up. I rebooted again and got the same result. I then re-enabled VT-x and it worked just fine - finished the setup wizard, failed to install 2 devices (normal for my tests), and displayed a stable desktop.

Has anyone else played with VT-x lately?

[SomeGuy]

All VT-x should do from the perspective of the OS is speed things up or slow things down a bit. The differences you are seeing in behavior are, as I understand it, an the result of intermittent timing specific memory management problem. I think some people are quick to blame VirtalBox/VT-x for the "Mshtml.dll" error and similar, but it happens on real hardware too.

[DOSGuy]

I've been running ReactOS exclusively in Bochs for months, and I get an error at mshtml.dll. ROS offers to install Gecko, I say yes, and it immediately continues installing files without installing Gecko. I've also used ROS in QEMU, but I haven't run ROS in VirtualBox for about a year.

[vicmarcal]

I've been running ReactOS exclusively in Bochs for months, and I get an error at mshtml.dll. ROS offers to install Gecko, I say yes, and it immediately continues installing files without installing Gecko. I've also used ROS in QEMU, but I haven't run ROS in VirtualBox for about a year.

Could you provide a link to the Bock version you are using?
Let's see if Bochs shows any new/more info about the bug
The problem is in the MM and ReacrOS devs qere able to replicate it with a test.It opens the foors to a new hope(but MM is a T-Rex)

[DOSGuy]

Bochs 2.4.6 and 2.5 have no problem installing ReactOS.

I just installed r54683, which still fails at mshtml.dll, offers to automatically download Gecko for me, and then instantly gives up and continues registering DLLs. I watched the Bochs Console the whole time -- which throws up hundreds of messages per minute during the installation process -- but nothing came up before or after the mshtml.dll fail. Bochs wasn't unhappy about anything the CPU, memory, or any other hardware was doing at that point.

Just out of curiosity, it's obvious that the DLLs are registered in alphabetical order. If the order was changed and mshtml.dll was moved earlier or later in the process, would it still fail at mshtml.dll, or would it fail on some other DLL? If the bug isn't in mshtml.dll itself, then why does the registration process always fail on that file and not some other file? Is it the largest? Is there something else that's special about that library?

[Haos]

This bug IS NOT specific to mshtml. Removing this dll will cause this bug to happen on another one.

[Bblaauw]

( edit: I really like the most recent newsletter on website's front page, very informative! )

Just to be clear, which ISOs are people using? I tend to stick to the 'bootcd-nnnnn-dbgwin.iso' as they're CMAKE-generated and thus also include Gecko installer.

The problem part is below (from QEMU), which apparently happens during/after MSHTML. If they already knew how to fix this ReactOS 0.3.14 would be out already
Plenty of fixme/stub/relocating stuff as you can see.

Code: Select all

WARNING:  MmFlushVirtualMemory at P:\Trunk_slave\x86_CMake\build\ntoskrnl\mm\ARM3\virtual.c:1044 is UNIMPLEMENTED!
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\wintrust\register.c:1161) stub
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name xul.dll (10000000 -> 019E0000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name js3250.dll (10000000 -> 02CB8000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name nspr4.dll (10000000 -> 01261000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name nss3.dll (10000000 -> 02DD3000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name nssutil3.dll (10000000 -> 0129C000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name plds4.dll (10000000 -> 00D43000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name plc4.dll (10000000 -> 012B1000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name smime3.dll (10000000 -> 012BB000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name sqlite3.dll (10000000 -> 02E9E000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name ssl3.dll (10000000 -> 02F1B000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\gecko\1.0.0\wine_gecko\xpcom.dll
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\user32\misc\stubs.c:514) SetProcessDPIAware is UNIMPLEMENTED!
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\dwmapi\dwmapi_main.c:60) 0123CF78
(P:\Trunk_slave\x86_CMake\build\dll\win32\wshtcpip\wshtcpip.c:188) Unknown level: 6
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\iphlpapi\iphlpapi_main.c:2008) (Handle 0359FE04, overlapped 0359FE0C): stub
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\iphlpapi\iphlpapi_main.c:2476) :stub
(P:\Trunk_slave\x86_CMake\build\ntoskrnl\se\semgr.c:299) SidInToken Calls: 40000
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\mshtml\main.c:274) stub 1 (null): returning S_OK
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\system32\msi.dll (77790000 -> 03990000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\System32\usp10.dll
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\oleacc\main.c:86)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\system32\olepro32.dll (77B20000 -> 03990000)
(P:\Trunk_slave\x86_CMake\build\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: C:\ReactOS\system32\ole32.dll
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\olepro32\olepro32stubs.c:47) stub
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\pstorec\pstorec.c:372)
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\rpcrt4\rpcrt4_main.c:643) (): stub
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\shdocvw\shdocvw_main.c:146) (TRUE, (null)): stub!
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\shell32\shell32_main.cpp:1475) TRUE (null): stub
(P:\Trunk_slave\x86_CMake\build\subsystems\win32\win32k\ntuser\keyboard.c:1082) err: No Window for Translate.
(P:\Trunk_slave\x86_CMake\build\subsystems\win32\win32k\ntuser\keyboard.c:1082) err: No Window for Translate.
(P:\Trunk_slave\x86_CMake\build\subsystems\win32\win32k\ntuser\keyboard.c:1082) err: No Window for Translate.
(P:\Trunk_slave\x86_CMake\build\subsystems\win32\win32k\ntuser\keyboard.c:1082) err: No Window for Translate.
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\urlmon\urlmon_main.c:173) (TRUE, (null)): stub
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\winhttp\main.c:73) ()
fixme:(P:\Trunk_slave\x86_CMake\build\dll\win32\wininet\wininet_main.c:39) (TRUE, (null)): stub


Also the following seems to spam the logfiles recently:

Code: Select all

(P:\Trunk_slave\x86_CMake\build\ntoskrnl\ps\query.c:1609) No execute support not implemented


as well as the following when starting installed ReactOS (yes these odd chars are really in the log, same for the surprise removal ACPI thing).

Code: Select all

(P:\Trunk_slave\x86_CMake\build\ntoskrnl\ps\query.c:1609) No execute support not implemented
(P:\Trunk_slave\x86_CMake\build\ntoskrnl\ps\query.c:1609) No execute support not implemented
(P:\Trunk_slave\x86_CMake\build\ntoskrnl\ps\query.c:1609) No execute support not implemented
(P:\Trunk_slave\x86_CMake\build\base\services\svchost\svchost.c:65) Could not open service key (SYSTEM\CurrentControlSet\Services\☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥►☻►☻►☻►☻►☻►☻é♥é♥é♥é♥é♥é♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥
☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥►☻►☻►☻►☻ ☻\Parameters)
(P:\Trunk_slave\x86_CMake\build\base\services\svchost\svchost.c:65) Could not open service key (SYSTEM\CurrentControlSet\Services\☻ ☻►☻☻♥►☻►☻►☻►☻\Parameters)
(P:\Trunk_slave\x86_CMake\build\base\services\svchost\svchost.c:65) Could not open service key (SYSTEM\CurrentControlSet\Services\♥►☻☺♥►☻☺♥ ☻☺♥ ☻ ☻►☻►☻►☻►☻►☻►☻►☻\Parameters)
(P:\Trunk_slave\x86_CMake\build\base\services\svchost\svchost.c:65) Could not open service key (SYSTEM\CurrentControlSet\Services\☻\Parameters)
(P:\Trunk_slave\x86_CMake\build\base\services\svchost\svchost.c:65) Could not open service key (SYSTEM\CurrentControlSet\Services\☻☻♥►☻☻♥ ☻☻♥☺♥H☻►☻►☻►☻►☻►☻►☻►☻►☻►☻↕♥►☻►☻0☻►☻►☻►☻►☻¶☻¶☻►☻↕♥►☻►☻►☻¶☻↕♥►☻►
☻►☻►☻►☻☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥☺♥►☻☺♥☺♥☺♥☺♥☺♥☺♥☺♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥►☻☻♥☻♥☻♥☻♥☻♥☻♥☻♥☻♥\☻c\Parameters)
(P:\Trunk_slave\x86_CMake\build\ntoskrnl\ps\query.c:1609) No execute support not implemented
Boot took 16840391625 cycles!
Interrupts: 1571 System Calls: 13972 Context Switches: 1983
(P:\Trunk_slave\x86_CMake\build\ntoskrnl\ps\query.c:1609) No execute support not implemented
(P:\Trunk_slave\x86_CMake\build\base\services\umpnpmgr\umpnpmgr.c:3183) Surprise removal: Root\ACPI_HAL\0
DHCPCSVC: DHCP service is starting up


[milon]

This bug IS NOT specific to mshtml. Removing this dll will cause this bug to happen on another one.

Odd. I've gotten around the problem (under VirtualBox) by:
1) Deleting mshtml.dll between the 1st and 2nd install phases. It didn't hang on any other dll.
2) Increasing RAM to 512MB.
I guess there's more going on than I understand, otherwise 1) above wouldn't be a successful way to install ROS.

All VT-x should do from the perspective of the OS is speed things up or slow things down a bit. The differences you are seeing in behavior are, as I understand it, an the result of intermittent timing specific memory management problem. I think some people are quick to blame VirtalBox/VT-x for the "Mshtml.dll" error and similar, but it happens on real hardware too.

The perspective of which OS? Host or guest? If it only affected the timing of things, I would expect that "VT-x off" would cause no additional problems, and "VT-x on" would be able to introduce new problems. But again, there's probably more going on here than I understand.

[vicmarcal]

1) Deleting mshtml.dll between the 1st and 2nd install phases. It didn't hang on any other dll.
2) Increasing RAM to 512MB.
I guess there's more going on than I understand, otherwise 1) above wouldn't be a successful way to install ROS.

Deleting the dll doesn't ensure that the setup wont hang in other dll. As this is related to timing, maybe deleting it worked in your case but is not a 100% solution to avoid the bug.
Iirc, problems are related to VT-X (a bug in our code not in Vbox) so just disabling it in the VM should help to avoid the bug. This is,afaik, the 100% solution to avoid the bug. There are other ways as installing VBOX 3.X since it doesnt use VT-X by default.

[DOSGuy]

Bochs doesn't support VT-x and the installer still hangs at mshtml.dll for me in the dbg build. I just tried it this morning with the windbg build, and while it spent several minutes at mshtml.dll, it did ultimately move on without complaining.