First I tried to update from 5.90 then I tried lite install over that build then I tried a stand alone lite install. Each time I was met with a black screen. Task manager revealed the following gMotor2 error. "Error creating standard shader". This happens when trying to launch both Single and Multiplayer. Specs as follows: Antec Nine Hundred Two Case, HIS Radeon HD 6970 ICE-Q Turbo 2GB, Akasa PowerMax 850W Power supply, Asus P6T Motherboard LGA1 366 Intel X58 ATX RAID SA, Intel Core i7-920 D0 Step Processor (8M Cache), Corsair Vengeance 12GB (3X4BG Sticks) DDR3 Memory 1600MHz, Noctua NH-U12P CPU Cooler SE1366, LG GH22NP20 22x DVDRW/ RAM, Seagate Barracuda 7200.11 1.5TB Hard Disk Drive 72 (Two), Windows 7 Premium 64bit Edition. Including SP1 and fully updated. No overclocking done and everything running at stock speeds.
How did you try a standalone lite install. I have one method and one only if I had trouble. 1. DO NOT uninstall rFactor2 2. RENAME your rFactor2 folder to rFactor2OLD 3. Run LITE installer point to your orginal rFactor2 folder ( either a EMPTY folder or let installer re-create it ) 4. TEST ...DO NOT add any old files as yet.
If last Build was running fine, you have not changed any drivers since, did a bare folder lite install and got same result with update and lite. Got me.
also here, 660 not start. http://isiforums.net/f/showthread.php/19382-Build-660-Released?p=266595&viewfull=1#post266595
I think the problem is your PC case and DVD drive. Sorry I just had to, I giggled when I saw those in the spec to determine this problem. Yes I am sad
used updater, first attempt at launch it said i had no DX9 video card installed, tried again and it was fine
I also had the black screen problem and message "Error creating standard default shader". This problem did not exist in 590, nor in any prior versions. There is a serious bug in 660 involving permissions which exists even when logged in as administrator. I did observe that the "users" group does NOT have write permissions with "Launch rFactor.exe" and "rFactor2.exe". Disabling Symantec 360 and giving the launcher full trust had no effect. The temporary work-around is as follows: 1) Right click the file "Launch rFactor.exe" and select "Properties" 2) Select the "Compatibility" tab 3) Check "Run this program as an administrator", then click "OK" View attachment 12324 Note that my core install is "Program Files (x86)" and data is "Documents". I'm running Win 7 Ultimate 64-bit. If anyone is interested, error info in the event viewer: Activation context generation failed for "F:\Docs\rFactor2\Support\Tools\MAS2.exe".Error in manifest or policy file "" on line . A component version required by the application conflicts with another component version already active. Conflicting components are:. Component 1: C:\Windows\WinSxS\manifests\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac.manifest. Component 2: C:\Windows\WinSxS\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2.manifest. AND Faulting application name: rFactor2.exe, version: 1.6.6.0, time stamp: 0x534c454d Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x72505c3a Faulting process id: 0x48c Faulting application start time: 0x01cf596366ed315b Faulting application path: F:\Program Files (x86)\rFactor2\Core\rFactor2.exe Faulting module path: unknown Report Id: c3c39d92-c556-11e3-9827-4061869494db
I dont care about the mas.exe or the rfactor.exe right now. Only the Launcher rFactor.exe How did you install build 660? If using an install; Was it a clean install or on top of existing installation? What installer did you use? Why is F: your windows drive and not C: ?
Hi Jeremy 1) OS is on C: drive (SSD). 2) Windows "Libraries" moved to F: (RAID 10) using GUI. 3) "Program Files (x86)" exists on both C: and F: and both dirs have same perms/ACL including "TrustedInstaller". 4) I have both UAC and DEP enabled. Tried installing lite over the existing install; tried updating through the Launcher; tried clean install. All with same result. Uninstalled and reinstalled 590 which worked fine. Downloaded lite again from other server. Did another clean install of b660 - still same error message. In all cases, before installation, I had cleared "F:\Docs\rFactor2\UserData\Log\Shaders". When doing the 1st run, the splash screen would display and then immediately the display goes dark. One shader file would be created in the "Shaders" dir, then the crash would occur when attempting to create the "standard default shader". Never had this problem with any build prior to b660. The "user" group in the rFactor2 folder had "read" and "read & execute" privileges. Once I allowed the group to have "Full Control" in the rFactor2 folder, b600 loaded normally without error. Alternately, the solution I described earlier, "run as", also works. Either way, this compromises the security of the system. Nobody should have write privileges in the programs directory. MS Office and Norton 360, for example, do not have write privileges in the same "Program Files (x86)" folder. System is fully patched with latest HW drivers/BIOS. I have it locked down tighter than most due to the nature of the programming and data I work with, but don't think this has any bearing. Also checked firewall and Norton 360 logs - didn't notice anything unusual.
" I have it locked down tighter than most due to the nature of the programming and data I work with, but don't think this has any bearing" rFactor2 needs a place to write files. The data and settings choice made during install is one opportunity to set that writable path. In the case data and settings are in a sub directory of program files; Windows forwards unsatisfied read and write requests to C:\Users\<name>\AppData\Local\VirtualStore. I just had my self and another engineer just retest this extensively without any issues outside of some less than desirable font rendering. "F:\Docs\rFactor2\UserData\Log\Shaders" is not the a standard location for Windows 7 for the user group. C:\Users or F:\Users is the start of that path. Windows does not forward failed reads or writes to VirtualStore in this case. "MS Office and Norton 360, for example, do not have write privileges in the same "Program Files (x86)" folder." True and neither do we. But, maybe mistakenly, we give you the option to store content where you want. I assume neither MS Office nor Norton 360 gives this as option since they are not dealing with GBs of data files. We try to give the user the option. What does you data.path file contain in <install path>\Core\Data.path ? That ever that points to needs to writable to the user that starts the Launcher. "Nobody should have write privileges in the programs directory" Admins do to install files. After that rFactor2 does not need to run as Administrator unless other security mechanisms put in place by the end user require it. However, there are programs (rFactor1) that were built before this security policies were implemented (Vista) that did write to Program Files. For backwards compatibility; this is why Windows forward things to the VirtualStore folder.
"rFactor2 needs a place to write files." Of course, that is why MS Office, my programming IDE project settings, etc. write to "My Documents". "F:\Docs\rFactor2\UserData\Log\Shaders" is not the a standard location for Windows 7 for the user group. Not sure what you mean here, but this is "F:\My Documents\rFactor2\UserData\Log\Shaders" in Windows so it is the standard location. This points to "F:\Docs" (the real dir name) using either a symlink or junction (can't remember which) that Windows itself created. This is also a common configuration on Windows servers with external, hardware based RAID. For example my 8 CPU server and multiple blade servers that are attached to a fiber IP SANS have only the base OS installed on local RAID 1 disks. All apps and data reside on the SANS. Also, Windows allows movement of all "Libraries" to any disk subsystem that is desired (not the case with the "User" dir). "But, maybe mistakenly, we give you the option to store content where you want. We try to give the user the option." No, you're doing exactly as you should. Doing otherwise would preclude people like me who have special requirements from using rF2. "What does you data.path file contain in <install path>\Core\Data.path ? That ever that points to needs to writable to the user that starts the Launcher." I thought of that also. It's the same as it was in b590 "F:\Docs\rFactor2". "'Nobody should have write privileges in the programs directory' Admins do to install files." I was trying to be brief here and probably should have added "except admins". Even then, UAC kicks in and asks permission to make registry changes. By the way, my UAC slider is set to 3/4. "For backwards compatibility; this is why Windows forward things to the VirtualStore folder." Absolutely true. I had a little time this afternoon to do some more testing. Uninstalled b600, wiped all directories, reinstalled lite b660. On 1st run, splash screen displays then the display goes dark. CTRL-ALT-DEL to desktop and there's the error message "Error creating standard default shader". I checked "F:\Docs\rFactor2\UserData\Log\Shaders\" and there was only one file "shaderMAS.hash" (which means that rF2 is able to write in that directory). The contents of the file contain two hashes: c23b779bdd66630950d590a7067aded174554c062fe6299386bec0e611b97981 707ffdbb0d525fc2911f6451a21392c33534b38edcdd881e2281531b04625916 Apparently, rF2 b660 fails after writing this file. Still the same error messages in the event log. I was logged-in as "Admin". Don't know what's different from b590 and earlier which worked and still works fine. Is there any attempt to create temp files in the install directory? After setting the launcher to "run as admin", rF2 b660 loads and runs normally. I then deleted all contents of the shader dir and allowed rF2 to recreate them. The file "shaderMAS.hash" was again present and the two hashes the file contained were identical to above. I also disabled "DEP" (Data Execution Prevention) and this is not related to the problem. Disabled Norton 360 AV realtime protection with no effect. I suspect that there's still protection running anyway (registry, boot strap, heuristics). Also checked environment vars TMP, TEMP which point to a subdir on the G: partition of the RAID 10 array. Also checked PATH. I wonder if the last Patch Tuesday of Windows and subsequent Norton 360 upgrades have anything to do with this. Also, I wonder if this is related to this specific version of Windows (OEM Ultimate which has different features e.g. shadow copies)? I'm stumped. How about a quick "diff" on b590 and b660 exe sources to see if anything was overlooked? Could this be related to QT somehow? By the way, glad to see the OpenSSL implementation is at 1.0.1g (libeay32.dll).
Yet another person with this same problem .... http://isiforums.net/f/showthread.php/19446-660-build-all-black?p=267448&viewfull=1#post267448 I'm beginning to think it has something to do with the change from Qt4 to Qt5.
Also observed when uninstalling using "Programs and Features" that the Qt5* files were not removed. Is this as intended? Same perms problem: http://isiforums.net/f/showthread.php/19446-660-build-all-black?p=267448&viewfull=1#post267448 http://isiforums.net/f/showthread.php/19404-Can-t-update?p=267328&viewfull=1#post267328
For us, Before we reinstall any software, when the option is to remove it to repair or update. We use a program called: Revo Uninstaller. http://www.revouninstaller.com/ Best frigging software I have ever come across. It has 3 phases. It creates a backup of the registry Does the Uninstall Then removes all extra directories ans registry entries that the software created. There are more that it does also, but the above are the things find work for what I am trying to do. There is a 30 day full free version available, then to purchase, is well worth the cost. Check it out.. Dave NRT
I have never tried that one... There is another great program we use faithfully on not only our computers, But the servers also. Winaso.. http://www.winaso.com/ The extra options the software does... are great. It is amazing the extra crap and registry entries that the simplest of software add. I believe in keeping my gaming stuff..as well as our servers to the basic programs and scripts running to a minimum. These 2 as well as Malware Bytes..are great for making this happen http://www.malwarebytes.org I find Malware Bytes, doesn't seem to cause issues like Norton Trend Micro, and the free ones that are out there like Avast But each to there own.. Dave NRT
It could be, but we may never really know for sure. The current "just run as admin" campaign has whittled the 5-10 people with this problem out of a several thousands to near zero. Making the possibility of finding a common indicator of this problem difficult http://msdn.microsoft.com/en-us/library/windows/desktop/bb762280(v=vs.85).aspx There is no \Docs or \Documents or any of that. The fact that you have "F:\Docs\rFactor2" in in your data.path means this is the EXACT path you chose. It is NOT the standard location the installer chose unless the path to Core is also writable. If the updater cannot write there like you suggest then neither will the simulation. It would kinda of indicate there is no write permissions there. There are few reasons why I think that 1) The path must have been created during install (from the installer) when user had escalated permissions. 2) The path is there based on end user statements. 3) Despite it's existence, once user permissions are deescalated from admin the directory is not writable. 4) The path in data.path is the EXACT path that rfactor2 will attempt to write to. It is not in the scope of virtual store forwarding. Therefore permissions must be correct. The only way I get this problem to happen is to switch users after install. However, I think that is how it should be. One user of a system should not be able to write to a path of another or update and install of another. That is my final reason. I have no other set of steps to recreate this issue other than to install under one user and install data and settings to C:\Users\thatuser and then try to run that same install from another user that has a data.path of C:\Users\thatuser instead of C:\Users\anotheruser
Spent a few moments trying to further discern why b660 is causing so many issues when all earlier versions install/update/run correctly. I ran a Windows troubleshooting report to see what would be reported ... View attachment 12442 Note that rF2 is not compatible with the version of Windows I have installed (OEM Win 7 Ultimate SP1 64 bit - fully patched). Clearly there is a problem. Unfortunately, the Windows Troubleshooter doesn't give any more detail. I'm sure the Microsoft "Application Compatibility Toolkit" would be more specific, but I don't have the that installed. I'm reasonably sure if I install the core to a folder outside of "Program Files (x86)", there would be no problem since basically, this would allow rF2 to do anything it wants - it would run similar to an XP application. An obvious security risk since rF2 connects to untrusted networks when using mp. "The fact that you have "F:\Docs\rFactor2" in in your data.path means this is the EXACT path you chose." Yep (except I selected "My Documents" through the installer). There is no "My Documents" on the "C" drive - my SSD. Again, I moved "My Documents" to the "F" drive using built in Windows menus. There is a junction (symbolic link) that Windows created that points "My Documents" to "F:\docs". If I right click "My Documents" in file explorer and copy the file name, it is "F:\docs". As far as Windows and applications are concerned, they are one and the same. "It is NOT the standard location the installer chose unless the path to Core is also writable." Yes it is by "Trusted Installer" (full control) and also by "CREATER OWNER" (full control). Check the security tab on "Program Files (x86)\rFactor". Also, I'm always logged in as Admin, so that is not the problem.
