RBR crashing on launch but before the profile selection (usually with the RichardBurnsRally_SSE.exe has stopped working or Visual C++ Run-time Library error message) is obviously a more complex matter as it can so easily be just about anything but a DEP related issue – although it's not totally out of the question (an error message doesn't necessarily eliminate this possibility). However, you should still primarily focus on other possibilities like a plugin (the likeliest culprit) or a mod you may have installed a minute ago.

Like if you do suspect a plugin, it should be easy to test. Just disable it in one way or another (renaming the main file from *.dll → *.no is the easiest method) and run the game again to see what happens. Depending on a plugin, it could be a simple case of missing files in its own subfolder and reinstalling it may magically fix the issue (although if this was true, you really should consider changing or at least updating your archiver). If the issue persists after reinstallation or two, then it may be wise to begin eliminating a potential DEP issue next.

None of this probably helped you in any meaningful way and it wasn't meant to, let's get that right, as this is one of those issues where all we can really say is "good luck!".

The primary solution is to do what you're told, so download and install DirectX End-User Runtimes (June2010). (Note that directx_Jun2010_redist.exe as such doesn't install the DirectX files, it only extracts the installer files to the location of your choice. The actual installation then begins by running DXSETUP.exe.) 

open \Plugins\FixUp.ini: centerMenu=0 → centerMenu=1

To clarify: RBR doesn't crash, it continues to run normally otherwise, so unless you've muted the menu sounds/music you should still hear them.

The solution is to right-click on RichardBurnsRally_SSE.exe → Properties → Compatibility tab → check Disable desktop composition. That should do it.

So you can get out of the game, but you can't return to the game. This is perfectly normal as alt+tabbing works only in windowed mode (RichardBurnsRally.ini: fullscreen=false). 

Before anything else, let's make it very clear what these issues are NEVER about: Visual C++. And also, you can easily make the game crash by impatient alt+tabbing during the loading screen, so above all, respect the game! #RespectRBR

Porridge has heard there are roughly three ways of how RBR would crash during a splash screen: 1) Loading freezes to about 25% and pressing any key exits the game instantly; 2) the Visual C++ Run-time error complaining about... well, whatever it complains about; and 3) loading stops at 50% because you amateurishly forgot to import the model to \Cars (in fairness, from 50% onwards, it should "always" be about the car). There may be some subtle variations to these but porridge wouldn't know because RBR has never crashed on him.

Generally writing, the problem is with either the car you selected or the stage you're going to. Or both. Or something else entirely. Simple as that.

(Nov 2020: Added the 2nd point based on information shared by heartbeat60 and Igor Borgacci, thanks guys!)

If we were to leave possible antivirus and Windows 10 features aside (that can often be countered by using the windowed mode, or – and this is quite revolutionary – by adjusting their settings) and focus purely on RBR, then you may find the culprit(s) from the following:

1) Flawed sound or co-driver mods, often self-inflicted by some heavy modding. For instance, a single pacenote would crash the game if its Snd0 line is missing (the crashing should happen every single time when that particular pacenote is about to be triggered).

2) For some gamers – by no means everyone – playing without VSync can cause freezing/crashing that would usually occur at specific points but not necessarily on every run of stages such as GB Sprint Extreme and Swiss (they are the known examples, there may be others). 

That's normal because any changes would need to be saved into the profile (like MULLIGATAWNY) too, so changing settings during a stage is only meant for temporary changes. The only way to actually save your profile is via Options in-game.

(First it's absolutely crucial to differentiate RBR's basic feature discussed in the chapter above from the nasty and more surprising issues covered in this chapter!)

There are known cases – albeit rare – where the controls are not saved at all if a desktop shortcut is linked to RichardBurnsRally.exe instead of RichardBurnsRally_SSE.exe. So always link the shortcut straight to _SSE.exe. (Obviously running the game via RBRCIT is more than recommended and none of this should be of any concern with RBRCIT.)

If you play in windowed mode and your controls tend to disappear always when resuming RBR – forcing you to re-assign them everytime – something's gone horribly wrong, let's get that absolutely right. What you should do is to go to your SavedGames folder and delete pfYOURPROFILE.acm (a file that contains only your controller settings) and then re-assign the controls in-game. And, to avoid the same issue in the future – if it hits you once, it'll probably hit you again – you may want to make the .acm file read-only after you have re-assigned everything again (known in the trade as The Borgacci Method). 

Open input.ini and change the problematic controls from false → true. However, if you need to invert FFB (not that I've ever heard of anyone needing to do that), the option can be found in-game. But please, do read the next chapter as well.

(Note! This fundamental RBR bug has now been fixed courtesy of mika-n as part of his fantastic plugin NGPCarMenu.)

It's an annoying bug, no doubt, but at least it's the same for everyone! To normalise them, you have to remember to use them on the start line and it'll be fine. We can assure you that you'll forget to do that every now and then, but that's all part of the annoyance! Note that the same issue recurs when resuming RBR in windowed mode, so it's not exactly advisable to go and surf the net mid-stage.

The game's default degrees centre-to-lock is a modest 60 for the wheel animation, but you can change it to anything you like by first extracting LM_Driver.ini from Misc.rbz to \Misc (create it if needed) and then edit its line Max Steeringwheel degrees. Care! Turn off the file's read-only attribute before editing. You can read more about files located in Misc.rbz here.

An alternative and perhaps more preferable solution to the hardcore is to remove the steering wheel (either with RBRCIT or even manually) and get rid of this snag altogether.

Excerpt from the current ReadMe.PhysicsNG.txt: "Only genuine NGP cars will work with [NGP6] plugin. All other cars are limited to using only reverse and first gear." This essentially means that with the NGP6 plugin, you can only use the official NGP6 cars put out by WorkerBee. To make this abundantly clear:

- You can't add to the car selection in RBRCIT by mixing NGP and vanilla physics anymore like you may have done in the past.

- The Original RBR Cars (also present in RBRCIT) will not work either, simply because they do not have NGP physics.

In both of these cases, NGP's own showRevision (enabled by default) would read like this on a special stage:

Next Generation Physics rev. ### INACTIVE !!! (required rev. ###) NO GENUINE NGP CAR

However, if you do get this problem with what is supposed to be a real NGP6 car, simply Update carList.ini → re-download NGP plugin just in case → Update All Existing Physics in RBRCIT, and test the same car after re-applying it. In more complex cases, this may not be enough but it'd be a waste of space to go through all eventualities. (I mean, one VIP once stated that re-downloading the model had fixed this issue for him but having since tested using a wrong 3D model on a car without a hitch, I'm not convinced.) 

Go to game's Options >> Gears >> Gear protection → off.

By "certain", porridge would mainly refer to classic format stages such as Swiss I + II (III and IV are fine), Fernet Branca and Verkiai, but the following nuggets will apply to other similarly heavy stages.

In RBR, two of the biggest frame rate stealers – ignoring FixUp's AdaptiveFFB now – that some stages are not particularly fond of must be Dynamic Car Reflections (better known as UseCubicEnvironmentMaps in RichardBurnsRally.ini) and the shakiness of the driver cam (cam_internal). Both have a pretty similar impact on FPS by comparison, but naturally the easiest and wisest move would be to disable the former (because it's pointless) and consider the latter only if you really want to have a static cockpit cam or if you wished to retain those allegedly dynamic reflections for whatever reason. (The easiest way to set up static driver cam comes with NGPCarMenu)

You could do both, of course, but let it be known that there would be no real upside in terms of frame rate (on the mentioned stages, at least) and even if there was, it'd be next to nothing.

Another classic optimising measure has been to disable car shadows (RichardBurnsRally.ini: RenderCarShadow=false, add the line if needed), because at the end of the day, what do you need shadows for if you rather watched a screensaver than an RBR replay? Turning it off can indeed give you a small boost, but intriguingly – and porridge may be wrong about this – Fernet Branca is an absurd exception with its performance actually dropping a bit without car shadows. How can this even be, porridge wonders without a clue but then again, maybe you should test it yourself, and that is if you're truly interested which you probably aren't. To be fair.

(Do remember that sky options like Heavycloud Heavyrain are more ideal for testing the limits of your hardware than the usual default Crisp Clear would be, because they tend to be "heavier".)

The problem where frame rate takes a long time to normalise itself (even 10–20 secs), can only be about AdaptiveFFB. As FixUp's own readme clearly states, you should use AdaptiveFFB only with VSync. But that's probably only half of the story, because if you already have VSync enabled, and it's still doing it, which – according to some reports, at least – is indeed possible, it is likely because AdaptiveFFB isn't really meant to be used alongside the so-called gaming monitors (120hz or above). So while you can always try to fiddle with the ffbBufferCycles setting (0→1→2) first, you may also want to give in immediately and change back to the original, award-winning FFB of RBR.

(This fundamental RBR_RX bug was brought to our attention by Keeb, thanks!)

When one first drives any stage with Random/Bad Weather in either Quick Rally or RBRTM, and then goes to RBR_RX, the RX plugin would only be able to launch Cote d'Arbroz in rain. Apart from restarting RBR (surely the fastest way), the only trick to normalise this would be to return to another mode/plugin to start any stage with Good Weather.

One thing to note here, of course, is that this kind of jumping between different plugins without crashing wasn't even possible before mika-n's groundbreaking NGPCarMenu.

Change Render Quality from low to high in RichardBurnsRally.ini. Some addon stages (such as Northumbria, Bruchsal-Unteröwisheim and Undva) are known to not support the low setting.

From the official 1.02 patch notes:
"The black lines appearing on the road is caused by the users forcing the driver to use AF (Anisotrophic Filtering) and/or FSAA (Full Scene Anti-Aliasing). By default it is set to be application controlled, which the game works fine with. This can have other graphical side effects, such as poor looking fonts and 2D graphics, because if you force to use these techniques they are applied to everything that is rendered instead of the application selecting where to use it. Also it does degrade the performance." There you go. Couldn't have put it any better.

This will indeed happen if you disable vSync in FixUp, it is what it is. With some cars you may be able to just edit the camera in such a way that hides the flawed animation, but you can also let RBRCIT remove the wipers entirely from all cars, or, you can do the same yourself manually by opening a car's own IniFile: Find [i_wiper_r] and [i_wiper_l] and edit the line Switch = false → Switch = true.

Not an everyday occurrence, it has to be said, because not only it requires massive skin files, likely it'd crop up only on certain stages such as Shurdin and Ouninpohja (they are the known examples). At day's end, here are the two reasons that would usually cause this issue:

1) The car's textures have been exported with a "wrong" preset and the files have ended up unnecessarily gigantic because of it. You can try exporting the DDS files again; using the preset BC3/DXT5 should be enough for all textures, but if you'd like optimise even more, you can use BC1/DXT1 for anything non-transparent.

2) The car's texture quality is way too high (like 8192x8192), which would render a simple re-exporting insufficient. You'd also have to rescale the texture files first to something less excessive (like 2048x2048 or even 1024x1024). Fixing only the transparent files may be enough, or maybe not. If you're using a skin made by someone else and you're not that interested in doing the dirty work yourself, remember that you can always reinstall the default skin as they tend to be reasonable enough.

Important! Both of these flaws would be well capable of making the game crash during the loading screen too (especially for VR users).

Not only do you have to have the same car installed but also it has to be installed to the exact same car slot when watching replays, otherwise the replay will load but not play back. (Although let it be known that in RBRTM, there have been some rare and isolated cases where even a matching car and slot have not worked but they're just that: rare and isolated cases.)

Let's face it, the default settings are just fine for 95% and for those who know their English, the following table should not act as a substitute for FixUp's own documentation (ReadMe.FixUp.txt), it is merely complementing it. 
Note! In case you don't see FixUp.ini in \Plugins yet, that's because you have to run the game first.