The Iron Wolf
Registered
I used to have, not anymore (since I had to remove all overclocks till this gets solved). My observation is - it does not make difference with crashes.
Recurrent NVIDIA Driver Crashes and Erratic GPU Usage
- Thread starter ECAR_Tracks
- Start date
Gijs van Elderen
Registered
Have you tried setting everything back to default and start from there?
https://forum.studio-397.com/index.php?threads/what-causes-this.53872/#post-869318
The Iron Wolf
Registered
Thanks Gijs, I'll probably give it a try after I rule out a hardware problem with Oculus by running other game with native support to see if I get crashes there.
I have to admit, I am running with unusual resolution (1600x1440), 100 FOV and SGSSAA, so with all of this I am asking for trouble
Also, as I said if I switch to 1080p and usual monitor output, I've not seen crashes, though I don't play much that way. It's even not clear if it's rF2 fault, maybe vorpX does something to video driver that makes it hang. I couldn't find any other AA setting to make shadows not flicker/jumpy other that SGSSAA enabled through inspector. What AA are you using, in game?
Gijs van Elderen
Registered
Level 8, that's level 4 for gtx9xx and gtx10xx cards.
A gtx1080 should be able to run rF2 just fine with all display setting at maximum with a 1920x1080 or 1600x1440 resolution.
(Shadow blur reduces shadow flickering)
I've a titan black (gtx780ti with more vram). I've everything at max. When i'm alone on track i get +120fps in 1920x1080 single screen and +60fps with tripple screens + multiview.
I have to admit: I've reduced visible cars to 12 to keep fps high enough in first laps. I usually do 1-3 hour races offline. Field is spread out after a few laps.
For oval races 12 visible cars isn't enough.
100 cars at the nordshleife was not a problem for my rig.
The Iron Wolf
Registered
780Ti is awesome card. Gave it to my son, he plays any FPS no problem, with a 10 year old processor
All settings in game, you do not modify CP settings or Inspector, right?
I believe game uses MSAA, I wasn't happy with shadows at level 4 AA of in game. Everything else is maxed out.
All settings in game, you do not modify CP settings or Inspector, right?
I believe game uses MSAA, I wasn't happy with shadows at level 4 AA of in game. Everything else is maxed out.
Voltaic
Registered
@Marcel Offermans I reformatted my startup drive (C) and installed a clean Windows 10 from scratch. I installed a fresh Steam on my "C" drive and fresh rF2 on my "H" drive, after which I was able to run a few laps without issues. Just now I tried to load the Enduracers Corvette in the garage and got a sim motor error, something to do with the wipers, which crashed rF2.
I will keep trying, however the whole subscription system seems to be screwed up. I keep getting the "Downloading Workshop Items...4 Items Remaining" message, I had the same message before I reformatted my HD and installed a new Steam setup. Once again, I have Steam installed on my SSD startup drive and Steam Apps on a second larger drive where I re-downloaded and re-installed my Steam apps from scratch. I don't know what else I can try
I will keep trying, however the whole subscription system seems to be screwed up. I keep getting the "Downloading Workshop Items...4 Items Remaining" message, I had the same message before I reformatted my HD and installed a new Steam setup. Once again, I have Steam installed on my SSD startup drive and Steam Apps on a second larger drive where I re-downloaded and re-installed my Steam apps from scratch. I don't know what else I can try
Marcel Offermans
Registered
Voltaic
Registered
I did as you suggested, I unsubscribed to all non-ISI/Studio 397 and kept a few official cars and tracks. I went into a track, exited and when I tried to load Silverstone again rF2 crashed.
Other than the SimCommander for my AccuForce and the SimDash for my wheel's display, I have no other plugins. I can try without the SimDash if you suspect it, I can't drive w/o SimCommander though.
If the plugins are not at fault; could this be caused by something else in my system? Bad RAM? Although I have stress tested my PC and everything checks out fine.
PS; I just ran a full memory test, no errors.
Attachments
Last edited:
Marcel Offermans
Registered
I have had an extensive private conversation with @Voltaic about this matter and he does seem to have resolved this. I would like to invite him to share his findings with the community (as in general I don't make private conversations public without permission, and he can describe in more detail what he did).
WhiteShadow
Registered
It might be good idea to look Control Panel > Administrative Tools > Event Viewer > Windows Logs > Application and System logs to find out what is causing rF2 crashes.
Voltaic
Registered
Sorry for the delayed reply Marce.
After some research I was able to narrow down my issues to a hardware/software problem. As it turns out, there seems to be a USB .DLL problem with some chipsets, here is some of the discussion at SimXperience;
"@Marcel Offermans
Marcel, this is the meat of the discussion at SimXperience:
"I found the Project CARS/OSW similar thread about pid.dll.
http://forum.projectcars...-completely-stop-working
Post #30 is potentially interesting...
http://forum.projectcars...p;viewfull=1#post1167830
Text copied below.
"Got some (hopefully) great news - I wrote a wrapper .dll to sit between PCars and pid.dll to see what was going on with FF. I spat out logs from both PCars and Assetto Corsa to check the differences. PCars destroys the FFB effects every time you quit the track, the crashes always happen when subsequently recreating (downloading) effects. Assetto Corsa doesn't destroy effects until quitting, but I spotted that after destroying the final effect, it always calls SendForceFeedbackCommand(dwId, DISFFC_RESET) to reset the FFB (PCars doesn't do this). I inserted this into my wrapper when it detects all forces have been destroyed and hey presto, PCars no longer crashes when creating new effects again! Hopefully the devs will see this."
Yes, I have always suspected that it was the way that rFactor resets the FFB
when rFactor2 crashes the last line of the log is
hwinput.cpp 7874: Entered HWInput::Restart()
Originally Posted by: Richard Macnaughtan
I have a attached the rFactor2 log when it crashes
The last line is
hwinput.cpp 7874: Entered HWInput::Restart()
trace.txt (32kb) downloaded 2 time(s).
I figured that when it restarts the FFB then it caused some kind of bug to crash the game. It looks like they destroy the FFB every time you go back to the pits or start the game which creates this bug
Originally Posted by: Richard Macnaughtan
I think it is at a hardware driver error. I suspect that rFactor 2 is trying to restart the FFB or send some kind of command that the Accuforce doesn't like.
It will either crash as soon as you spawn in to the garage or when you get in the car or when you go back to the garage after a session.
And when I debugged the crash I saw that it was PID effect operation 56 which caused the crash. Maybe this is the same command which causes Project cars to crash.
Originally Posted by: Richard Macnaughtan
A bit more debug infomation
Exception Information
PID!PID_EFFECTOPERATION+56In rFactor2__PID__183932__Date__11_03_2015__Time_10_35_43PM__528__Second_Chance_Exception_C0000005.dmp the assembly instruction at pid!PID_EffectOperation+56 in C:\Windows\System32\pid.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x9c340010 on thread 14
Here is the full crash report
CrashHang_Report__Date_11_03_2015__Time_10_38_29PM__422.zip (19kb) downloaded 4 time(s).
Originally Posted by: Richard Macnaughtan
Even more debug infomation.
It looks like it is some type of memory access violation. I don't know why it only happens with the Accuforce plugged in and with the game running in 64bit mode
FAULTING_IP:
pid!PID_EffectOperation+56
00007ffd`922d2ada 8b540838 mov edx,dword ptr [rax+rcx+38h]
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ffd922d2ada (pid!PID_EffectOperation+0x0000000000000056)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000009b9c340010
Attempt to read from address 0000009b9c340010
SYMBOL_NAME: pid!PID_EffectOperation+56
MODULE_NAME: pid
IMAGE_NAME: pid.dll
STACK_COMMAND: .ecxr ; kb
BUCKET_ID: INVALID_POINTER_READ_pid!PID_EffectOperation+56
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ_pid!PID_EffectOperation+56
FAILURE_PROBLEM_CLASS: INVALID_POINTER_READ
FAILURE_EXCEPTION_CODE: c0000005
FAILURE_IMAGE_NAME: pid.dll
FAILURE_FUNCTION_NAME: PID_EffectOperation
FAILURE_SYMBOL_NAME: pid.dll!PID_EffectOperation
FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_pid.dll!PID_EffectOperation
I am not a programmer so I can't write a wrapper but I suspect this PID effect operation 56 is trying to destroy the FFB effects like Project CARS does and this causes a crash with some USB controllers while in 64 bit mode.
All this info backs up my hunches about how the games are resetting the FFB but I don't know why this is only happening on some USB controllers AND in 64 bit mode AND with the Accuforce. It seems like just that combo of hardware causes these problems and that is why it is so hard to reproduce.
Originally Posted by: Danyel Grenzer
Many many thanks to you, Richard
You really solved (at least) my problem, but USB 3.0 ins´t the issue in my case, it´s really only the chipset. My Gigabyte GA-H97M-D3H have to USB 2.0/1.1 physical ports with the same problems.
...the two USB-case-ports seems to solve this issue in rFactor 2 and pCars
So maybe those two ports are using a different USB controller chipset that isn't affected by this bug.
It really does seem like it is something to do with how certain USB controllers handle this FFB reset/PID effect operation 56 command.
The chipset for my USB 2.0 and back USB 3.0 works fine but the front USB must be using a chipset that has this bug. Same problem with Danyel, he must have 2 different USB chipsets, one which works and one which doesn't.
I guess the solution for this would be to just keep trying different USB ports until you find one that works and if all else fails then buy a PCIe USB card which doesn't have this bug like my Etron one.
Originally Posted by: Berney Villers
Richard/Mark - I should find a spot on payroll for you guys!
Nice work!
I probably would have sat here for another week trying to reproduce the issue and never would have since I don't have a USB 3.0 driver with the issue.
No probs. Glad to help"
"Originally Posted by: Berney Villers
As an FYI. Many motherboards have the Intel chipset provided USB and another USB chip that provides some USB 3.1, 3.0 and 2.0 ports.
Here is an example of the USB specs for the Gigabyte Gaming 7 motherboard, which has 3 variants:
Chipset:
1.5 x USB 3.0/2.0 ports on the back panel
2.4 x USB 2.0/1.1 ports (available through the internal USB headers)
Chipset+Renesas® USB 3.0 Hub:
1.4 x USB 3.0/2.0 ports (available through the internal USB headers)
Chipset+Intel® Thunderbolt™ 3 Controller:
1.1 x USB Type-C™ port on the back panel, with USB 3.1 support
2.1 x USB 3.1 Type-A port (red) on the back panel
This might explain why some folks have success by simply changing USB ports. By doing so, they're essentially changing USB chip and drivers to one that meets the standards and/or behaves better."
I am receiving a new PCI-e USB 3.0 board today that, according to other AccuForce users, resolves this issue. I will get back to you once I test it. BTW, I asked SimXperience to grant you access to their forums. Not that I carry any weight but I think SIM developers should be involved."
After some research I was able to narrow down my issues to a hardware/software problem. As it turns out, there seems to be a USB .DLL problem with some chipsets, here is some of the discussion at SimXperience;
"@Marcel Offermans
Marcel, this is the meat of the discussion at SimXperience:
"I found the Project CARS/OSW similar thread about pid.dll.
http://forum.projectcars...-completely-stop-working
Post #30 is potentially interesting...
http://forum.projectcars...p;viewfull=1#post1167830
Text copied below.
"Got some (hopefully) great news - I wrote a wrapper .dll to sit between PCars and pid.dll to see what was going on with FF. I spat out logs from both PCars and Assetto Corsa to check the differences. PCars destroys the FFB effects every time you quit the track, the crashes always happen when subsequently recreating (downloading) effects. Assetto Corsa doesn't destroy effects until quitting, but I spotted that after destroying the final effect, it always calls SendForceFeedbackCommand(dwId, DISFFC_RESET) to reset the FFB (PCars doesn't do this). I inserted this into my wrapper when it detects all forces have been destroyed and hey presto, PCars no longer crashes when creating new effects again! Hopefully the devs will see this."
Yes, I have always suspected that it was the way that rFactor resets the FFB
when rFactor2 crashes the last line of the log is
hwinput.cpp 7874: Entered HWInput::Restart()
Originally Posted by: Richard Macnaughtan
I have a attached the rFactor2 log when it crashes
The last line is
hwinput.cpp 7874: Entered HWInput::Restart()
I figured that when it restarts the FFB then it caused some kind of bug to crash the game. It looks like they destroy the FFB every time you go back to the pits or start the game which creates this bug
Originally Posted by: Richard Macnaughtan
I think it is at a hardware driver error. I suspect that rFactor 2 is trying to restart the FFB or send some kind of command that the Accuforce doesn't like.
It will either crash as soon as you spawn in to the garage or when you get in the car or when you go back to the garage after a session.
And when I debugged the crash I saw that it was PID effect operation 56 which caused the crash. Maybe this is the same command which causes Project cars to crash.
Originally Posted by: Richard Macnaughtan
A bit more debug infomation
Exception Information
PID!PID_EFFECTOPERATION+56In rFactor2__PID__183932__Date__11_03_2015__Time_10_35_43PM__528__Second_Chance_Exception_C0000005.dmp the assembly instruction at pid!PID_EffectOperation+56 in C:\Windows\System32\pid.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x9c340010 on thread 14
Here is the full crash report
Originally Posted by: Richard Macnaughtan
Even more debug infomation.
It looks like it is some type of memory access violation. I don't know why it only happens with the Accuforce plugged in and with the game running in 64bit mode
FAULTING_IP:
pid!PID_EffectOperation+56
00007ffd`922d2ada 8b540838 mov edx,dword ptr [rax+rcx+38h]
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ffd922d2ada (pid!PID_EffectOperation+0x0000000000000056)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000009b9c340010
Attempt to read from address 0000009b9c340010
SYMBOL_NAME: pid!PID_EffectOperation+56
MODULE_NAME: pid
IMAGE_NAME: pid.dll
STACK_COMMAND: .ecxr ; kb
BUCKET_ID: INVALID_POINTER_READ_pid!PID_EffectOperation+56
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ_pid!PID_EffectOperation+56
FAILURE_PROBLEM_CLASS: INVALID_POINTER_READ
FAILURE_EXCEPTION_CODE: c0000005
FAILURE_IMAGE_NAME: pid.dll
FAILURE_FUNCTION_NAME: PID_EffectOperation
FAILURE_SYMBOL_NAME: pid.dll!PID_EffectOperation
FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_pid.dll!PID_EffectOperation
I am not a programmer so I can't write a wrapper but I suspect this PID effect operation 56 is trying to destroy the FFB effects like Project CARS does and this causes a crash with some USB controllers while in 64 bit mode.
All this info backs up my hunches about how the games are resetting the FFB but I don't know why this is only happening on some USB controllers AND in 64 bit mode AND with the Accuforce. It seems like just that combo of hardware causes these problems and that is why it is so hard to reproduce.
Originally Posted by: Danyel Grenzer
Many many thanks to you, Richard
...the two USB-case-ports seems to solve this issue in rFactor 2 and pCars
So maybe those two ports are using a different USB controller chipset that isn't affected by this bug.
It really does seem like it is something to do with how certain USB controllers handle this FFB reset/PID effect operation 56 command.
The chipset for my USB 2.0 and back USB 3.0 works fine but the front USB must be using a chipset that has this bug. Same problem with Danyel, he must have 2 different USB chipsets, one which works and one which doesn't.
I guess the solution for this would be to just keep trying different USB ports until you find one that works and if all else fails then buy a PCIe USB card which doesn't have this bug like my Etron one.
Originally Posted by: Berney Villers
Richard/Mark - I should find a spot on payroll for you guys!
Nice work!
I probably would have sat here for another week trying to reproduce the issue and never would have since I don't have a USB 3.0 driver with the issue.
No probs. Glad to help"
"Originally Posted by: Berney Villers
As an FYI. Many motherboards have the Intel chipset provided USB and another USB chip that provides some USB 3.1, 3.0 and 2.0 ports.
Here is an example of the USB specs for the Gigabyte Gaming 7 motherboard, which has 3 variants:
Chipset:
1.5 x USB 3.0/2.0 ports on the back panel
2.4 x USB 2.0/1.1 ports (available through the internal USB headers)
Chipset+Renesas® USB 3.0 Hub:
1.4 x USB 3.0/2.0 ports (available through the internal USB headers)
Chipset+Intel® Thunderbolt™ 3 Controller:
1.1 x USB Type-C™ port on the back panel, with USB 3.1 support
2.1 x USB 3.1 Type-A port (red) on the back panel
This might explain why some folks have success by simply changing USB ports. By doing so, they're essentially changing USB chip and drivers to one that meets the standards and/or behaves better."
I am receiving a new PCI-e USB 3.0 board today that, according to other AccuForce users, resolves this issue. I will get back to you once I test it. BTW, I asked SimXperience to grant you access to their forums. Not that I carry any weight but I think SIM developers should be involved."
Voltaic
Registered
I then ordered one of the confirmed-compatible PCI-e card;
"@Marcel Offermans
Marcel
After limited testing once I received and installed this PCI-e card, I am happy to report I have not had any issues. I will be stress testing rFactor 2 tomorrow and get back to you."
And it has been working perfectly since then:
"Hello and happy new year Marcel
I am happy to say I have not experienced anymore rFactor 2 crashes since I installed the new PCI-e USB card. I hope this helps you and your team in the future, I will keep you informed if anything changes."
I don't know if this problem affects all controllers, I can say it was affecting all simulation games, I focused on rFactor 2 because it is my go to SIM.
If you own an AccuForce you will be able to login at SimXperience and view the ".DLL" thread with further information.
A great thank you to Marcel for his engagement with this issue! I hope this .
"@Marcel Offermans
Marcel
After limited testing once I received and installed this PCI-e card, I am happy to report I have not had any issues. I will be stress testing rFactor 2 tomorrow and get back to you."
And it has been working perfectly since then:
"Hello and happy new year Marcel
I am happy to say I have not experienced anymore rFactor 2 crashes since I installed the new PCI-e USB card. I hope this helps you and your team in the future, I will keep you informed if anything changes."
I don't know if this problem affects all controllers, I can say it was affecting all simulation games, I focused on rFactor 2 because it is my go to SIM.
If you own an AccuForce you will be able to login at SimXperience and view the ".DLL" thread with further information.
A great thank you to Marcel for his engagement with this issue! I hope this .