@Jeremy "Despite your assertion that I 'cannot', I most certainly can move one." Never said that - please don't misquote me. I'm only trying to help here and have the future of rF2 at heart. These problems are causing lost sales. http://isiforums.net/f/showthread.php/19556-Can-t-install-Bulid-660?p=269062&viewfull=1#post269062 The thing we don't know is how many new users tried the demo and couldn't get it to work. Most likely they would not post here and simply give-up on rF2. Also, if I offended you in any way, I'm sorry as that was not my intention. Given the size of the dev team, I think you're doing an outstanding job. I even re-upped my subscription during the time mp was broken (early I might add), so I must have a lot faith in the ISI team. Some of this I blame on myself. Due to other commitments, I didn't test the beta builds between 590 and 660. Also, please don't get discouraged. You should see all the problems Lockheed Martin had when it released P3D v2.0 (flight sim) in December. They upped DX9/DX10 to DX11, but were forced to stay at 32-bit because it would break backwards compatibility with existing add-ons. Prepare3D http://www.prepar3d.com/
First line http://isiforums.net/f/showthread.p...shes-on-launch?p=268632&viewfull=1#post268632 You might not know. Regardless, I have asked repeatedly for more information about your system and how you installed rF2. If you continue to solve this problem recommending compromising rF2 customers systems; please do so on a different domain, make millions on the solution, and live in house of chocolate and honey. These forum(s) are to solve rF2 problems not to tell customers to "Run rF2 (a mod-able video game) as Admin" which does nothing but snowballs one problem into many problems. http://youtu.be/qT2ALLXU2lY Windows 7 x64 ultimate N. Works fine. No compatibility no admin no nothing, just install and go. This machine is setup following what information you provided about your system. Result.
Wrong. Read this post again. http://isiforums.net/f/showthread.p...ibility-Issues?p=269134&viewfull=1#post269134 I clearly said that permissions, locations, etc. is not the answer and that I changed the TEMPORAY work-around. This has helped a number of people on this forum who could not get rF2 b660 to run otherwise. I also stated that this "may be the case with you" in the 1st post. I also did not say to use my recommendation: "Instead, try OTHER work-arounds that have been suggested. In MY case, running rF2 as admin in compatibility mode works. " Note the words "other" and "my case". You would prefer that people go for weeks without rF2 while they wait for a new build that that may, or may not, fix the problem? On a good note, you may have partially solved some problems by putting up the video. I immediately caught something at 1:09 and didn't need to finish the video (although I did). Notice the list of VC++ distributables at 1:09 in the video. Now, look at the list of installed programs on the machine I tried the demo on yesterday that had a fresh Win 7 Pro install with VC++ 2010 and 2013 already present. Test Machine View attachment 12490 Note that rF2 installed VC++ 2012, not VC++ 2008. Why, I don't know. That might make a difference eh? (I had previously installed 2010 and 2013). On my Ultimate dev machine, as I had previously told you, I have 19 VC++ entries listed (2005 thru 2013). So this might help: 1) If the installer sees a version of VC++ newer than 2008, it might not install VC++ 2008. 2) If the above is true, it installs 2012 (at least on my test machine) and likely uses that instead. 3) If a user has multiple VC++ redistributables, it appears that rF2 is getting confused. 4) This MIGHT explain why 590 and earlier builds worked, but not 660. 5) The launcher loads, but upon calling rFactor.exe, it black screens with error message "Cannot create default shader" or something similar. 6) Don't know yet if this is a Win 7 only problem, or if it impacts Win 8 as well. This would explain why Win 7 is flagging it as being incompatible and running it in compatibility mode works. It may also explain why some people are missing VC++ 2008 redistributables. So, in no way was your time wasted. Nor did you prove me wrong, though I may in the end have to concede that the cause was not what I anticipated. I'll test this hypothesis tomorrow, but my gut reaction is that this may be the root cause. I'll remove 2010 - 2013 and reinstall. Also, please don't threaten me. It sounds immature, you don't know who I am, and you probably don't want to know who I worked for. I'm also too old to get into a pissing contest. I already apologized to you if I slighted you in any way. Again that was not my intention.
Please referenced where I threaten you and I will have it removed and replaced with an apology. Please don't ignore this request. If you chose not to point this out I cannot continue in this thread and am forced to delete/close entire thread since I cannot locate said threat for surgically removal. Users are not allowed to make threats without moderation. So please point this out so I can see if I should have myself banned for threatening another user. Yes I would, 1) I would like to know the extent of the problem, Do we need to push for another update, is the problem wide spread? Right now, you are one of a very few. Its difficult to know how much time to allocate. Now I have to work on this after hours if I chose todo so. 2) I would like to look at multiple conditions from multiple machines to see if the there is a common theme. 3) I would never compromise a persons system to run a modable simulation, even one that pays my bills, if it is means that one of our customers could possibly have critical data compromised. The fallout of having just one customer having thier identity compromised to run our product is not worth it. A security hole that vectors through rFactor is not good for anyone. 4) Build 590 works. They are only losing access to the latest build according to your reports. Please reference [by reference I mean copy] where you describe your setup in detail. I don't see it anywhere. I have reread all your posts on this subject multiple times. Hopefully my comments below will save you some time. 1)If the installer sees a version of VC++ newer than 2008, it might not install VC++ 2008. Build 660 does not install 2008 runtimes. Note the dates in the attachment. Only VS2012 x86 was installed. Build 660 does not need the 2008 runtimes. 3) If a user has multiple VC++ redistributables, it appears that rF2 is getting confused. This is not true. rFactor.exe does not need any runtimes to run. 4) This MIGHT explain why 590 and earlier builds worked, but not 660. rFactor has used VC11 since the first build. Only the Launch rFactor.exe and SyncManager.exe need implicitly loaded C++ runtimes. If this is doubt; load up dependency walker and look for *110.DLLs. Only the launcher and syncmanager require them. 5) The launcher loads, but upon calling rFactor.exe, it black screens with error message "Cannot create default shader" or something similar. This would mean there is nothing wrong with the runtimes. a) rFactor2.exe is built with /MT option along with MAS.exe, ModMgr.exe, rFConfig.exe and rFactor2 Dedicated.exe. Our static libraries are as well otherwise we would get a link error. b) Its already too late, an executable will not even attempt to run if proper implicitly loaded dlls are not found. Arguing the possibility that function signatures did not change between import libs/export files thus allowing a improper DLL to be implicitly loaded would not only break the launcher but all application on the machine that would be loading said improper dll. What it could mean is your launcher is not launching the right rFactor.exe, the data.path is hosed, or for some reason the executable cannot read and/or write to where it thinks it can. Hard to know with information I have on hand. 6) Don't know yet if this is a Win 7 only problem, or if it impacts Win 8 as well. Dont know either, both work fine on my end so leaning it does not matter.
Jeremy Thank-you for the information. It cleared up confusion on my end regarding which VC++ redistributables should be present in Programs and Features. Did some initial testing on a Win7 Pro test machine and verified what you've said. Both the demo and lite b660 versions install C++ 2012 redistributables correctly. The 2008 didn't make sense to me based upon a prior post. I haven't had time to fire up Dependency Walker yet. Here is the list of *110.dll" on this machine: View attachment 12496 The two highlighted files are beta versions, but I don't know where they came from. All are version 11.x. "for some reason the executable cannot read and/or write to where it thinks it can." I agree this is one good possibility. If true, the question is why. Also, why does setting compatibility flags change this behavior on some versions of Windows 7 (it is then able to write all shader files and not just the hash file). There are 20 different versions of Win 7 Ultimate that MS has released that I'm aware of. The "N" versions are distributed in Europe and not the USA. On my Ultimate dev machine, I'm using an RTM version OEM which has been upgraded to SP1. The current versions of Windows 7 are designated with a "U". For example, "Windows 7 Ultimate x64 SP1 U". I'm assuming you tested with either: a) "Windows 7 Ultimate N x64 SP1", or b) "Windows 7 Ultimate N x64 SP1 U" The registry settings, system32 files, etc. are different for each version. Can you check something on the Ultimate machine that you tested? This would help greatly. 1) regedit 2) Navigat to this key: HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted 3) Jot down which rF2 applications have been flagged, if any. I want to check if the "System Application Compatibility Database" that Windows maintains is different. Windows properly sets Application Compatibility flags for the installer, but does not set any for the launcher unless set manually using the Windows GUI on this machine and apparently some others on this forum. I have a doctor's appointment, but I'll get back to this later.
The 2 *110.dll files you highlight are from .NET Framework 4.5. FWIW I have registry entries in that key only for the setup/sdk and uninstall EXEs. B118 is the earliest entry I have in my O/S installs so it seems it's been done this way for awhile now. TBH I don't install my main rF2 files I actually use to Program Files I only bother doing test installs to Program Files and then try various methods of screwing it up in order to try to replicate the mess some people manage to create for themselves. IMO it seems people mix and match how they do stuff, sometimes they run stuff from the launcher other times they try running the EXEs direct from the Core folder, sometimes doing it as Admin and they end up with half their files where they don't expect (or know about) in the VirtualStore. Fortunately the ModManager was redesigned to (hopefully lol) prevent a lot of the mess. All I can say if I follow the default install procedure it works everytime*. *Admittedly there have been one or two hiccups along the way the very latest seems to be you can't update B590 to B660 (assuming you don't have the x86 2012 runtimes) without it throwing a *110.dll error. Installing the runtimes before using the updater should work or just installing the Lite B660 over the top should do it and of course there's the little wrinkle with the config.ini creation.
C:\Users\tester\Downloads\rFactor2_DemoBuild_660.exe Is all I have. Carlo if you don't point out where I threatened you or retract your statement made above: This thread will be have to be closed before I leave work today and I got in pretty early. Rules are rules
Well I will assure you, they didn't come with windows. A clean install of Win7 would be a better way to prove if this problem is rF2, or something special about your setup. As for not being able to write stuff. If you have UAC enabled then your account isn't an admin and can't write to a lot of areas of the disk. Setting the "admin" compatibility flag forces it to run as an admin which is why it is then able to write anywhere. ISI defaults the Core to the Program Files folder because everything in the core is static. They put the DataPath in %USERPROFILE% because your user will always have full access to that path, even without running as admin. This is why they do a split install. This is how almost all game devs do it now. In all your testing... keep an eye on %USERPROFILE%\AppData\Local\VirtualStore. If an app tries to write to an area that is off limits it will redirect the output to that folder which just creates more confusion.
Hello Noel, I just checked my %USERPROFILE%\AppData\Local\VirtualStore and I do have an entry in there for rf2. Presumably when I ran the program as admin it did that. Everything seems to work ok without being admin anyway, I was just trying to find out why my mod manager doesn't like a network location (or mapped net drive) anymore, and why the uninstaller doesn't work. Hopefully the thread doesn't get locked or deleted, I have no idea how to unpick the mess I have made by running as admin, but it was certainly not right before I tried that as a solution to my couple of problems. I simply tried to update which has worked for me before, but this time failed, I didn't bother making a note of the error because I thought all things could be resolved by installing lite over the top of the previous install and emptying the shader and bash folders, which is what I did. Then I went to install some stuff using modmgr from my network location like normal which is when I got that problem, so I tried to uninstall rf2 which is when I realized the uninstall buttons in the launcher didn't work. So I used windows uninstaller which is when I realized that it was leaving behind all the rf2 files and folders and just deleting the program entry and shortcut. All of this occurred before I tried running as admin or any compatibility changing.
VirtualStore is where stuff goes when you are not running as admin. It is possible that you used to not run as an admin and it's been storing stuff there but now that you started running as admin it isn't looking there anymore. If a non-admin tries to write to an area that needs admin rights, it remaps the file io to the VirtualStore folder. It is completely transparent to the application. I would suggest everyone stick to ISI's default way of installing in two locations. The Core goes to Program Files and the datapath can go anywhere you want as long as the folder doesn't require admin rights. In your case I would move the rF2 related stuff out of the VirtualStore folder (incase you need some of it) and then going forward, be sure to put the datapath somewhere you have full access to. It think everyone wants rF2 to be just like rF1 and they install both the Core and DataPath into the Program Files folder not realizing it will cause problems because only admins have write access to Program Files. So then it starts putting stuff in the VirtualStore folder and confuses the crap out of people. I have never tried pointing the modmgr to a network path. I will try it on my machine and see what happens. Edit: I tested UNC network paths and it works for me.
What do you mean by network drive - a local LAN drive? Modmgr works fine with local LAN drives which are either mapped to a drive letter, or just as a network location, as I have been using it this way since forever. We are also using it with dropbox locations mapped to driver letters.
I just realized the one and only rfcmp I put in the folder for my test was corrupt. I can confirm that network paths are working fine. I didn't tested with a UNC path just fine.
I have always let it install to the default paths. Core to program files(x86) and data to my documents folder. I have always been able to access mods anywhere as well, just point mod manger there and it works. It is simply this time that something has happened. And I have not done anything different my end. I have also checked on another machine with the same win 7 64 version and the same thing happens.
Try renaming all your old folders. Then make sure the VirtualStore folder is rid of anything rF2 related. Then do a new install to the default paths. Be sure the both of the old rFactor2 folders are renamed or deleted. There is nothing important stored anywhere else on the disk that would impact a fresh install. The registry doesn't have any real impact so don't bother with that. Once you have done that... don't bother running as admin... just start the launcher normal and see what happens. Don't bother with plugins and don't install any content right away. Don't restore the UserData folder or plr files either. Keep it as simple as possible. If that works. Then try installing some packages (even from a network drive/UNC path).
I've recently installed rf2 build 660 onto win7 pro[OEM I think]. This was a fresh clean install of win7 pro. No using automatic updates. No installing anything other than I think motherboard drivers or lan drivers and logitech drivers and realtech drivers. No installing adobe, skype, firefox etc etc. Plays fine 99% of time but then got "rFactor has a problem and has to close" Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: rFactor2.exe P2: 1.6.6.0 P3: 534c454d P4: rFactor2.exe P5: 1.6.6.0 P6: 534c454d P7: c0000005 P8: 004722c5 P9: P10: My problem/point is this is a full on clean install of windows, I dunno if older builds or rF2 would do this. I also don't know if I can recreate this problem. Is this to do with whats being talked about in this thread, or can someone tell me what the info I posted etc means? Also, seems as thought windows media centre opened on its own and also I think internet explorer did the same thing. This was not during the crash, but during other times I was browsing internet or had alt tabbed out of rFactor. So thats off topic, but if things are opening on their own is that a clue or co incidence?
So I tried what you said Noel, and I still get exactly the same thing. Uninstall buttons in the launcher do nothing, mod manager hangs if I point to a location anywhere other than the pc rf2 is installed on. Since I have already tried going back to 590 (same result) I will try with an earlier build and see what happens. I think the registry might matter in this case, as 590 did work fine, and now that exhibits the same behaviour.
Jeremy, I notice you created a new library on F: and installed to it; is it possible what Carlo has described (subtly, across 2 threads) is going to his My Documents within his Users folder, Properties, and changing the Location? So it's Documents, but actually stored on the different drive. And if so, would that be any different? I was going to test with a VM but found I can't do virtualization and I don't really want to go playing with my installation that's plodding along just nicely...
