pouët.net

4k Crash/BEX Issues

category: code [glöplog]
Quote:
...are we talking about the same crash here...?

Given that both crashes depend on the graphics driver version, it seems likely that they are two different symptoms of the same underlying cause.

My guess is that the NVIDIA driver is modifying the contents of the executable during loading (graphics drivers are known to do such things), which, depending on the values/number of function hashes, results in different things breaking.
added on the 2012-10-18 09:35:40 by Blueberry Blueberry
Good that we have both Psycho and Blueberry present at TRSAC - if you guys have stuff to show in the compos, you might need to make it run on the compo machine first :D
added on the 2012-10-18 12:05:59 by Puryx Puryx
Okay, I know I'm missing something here and this is usually the point where ryg shows up and corrects me, but why does the graphics driver have access to the PE loader? I mean I can understand application detection / PE parsing after you've called Direct3DCreate / etc., but before...?
added on the 2012-10-18 13:11:56 by Gargaj Gargaj
Because graphics drivers use every trick in the book (and probably quite a few others) to make applications go faster than with competitors' hardware/drivers. I wouldn't put it past them to try to optimize things that have nothing whatsoever to do with graphics if they find it to be a bottleneck in some important application.
added on the 2012-10-19 13:58:12 by Blueberry Blueberry
yeah but what exactly do they win by hooking into the PE loader?
added on the 2012-10-19 14:02:33 by Gargaj Gargaj
Quote:
Good that we have both Psycho and Blueberry present at TRSAC - if you guys have stuff to show in the compos, you might need to make it run on the compo machine first :D

Shouldn't be a problem if you are not running an NVIDIA driver newer than version 301.42. Too bad if some 4k chooses to require OpenGL 4.3. ;)
added on the 2012-10-19 14:05:59 by Blueberry Blueberry
Yeah, finding out about this situation at Function after the intro compo deadline was... not fun. ("...What do you mean even Elevated crashes?")
added on the 2012-10-19 14:09:31 by Gargaj Gargaj
Blueberry: fun fact - there are no OpenGL intros yet reported to have that problem.
And - I have exactly the same drivers running here (4.3 devdrivers) and can't reproduce any of the problems.
So it might be a good thing to compare what happens, step by step. Maybe we can also figure out why stuff works here.
added on the 2012-10-19 23:58:52 by las las
Quote:

New in R304 Drivers:
[...]
Adds support for NVIDIA TXAA
NVIDIA TXAA is new film-style anti-aliasing technique designed specifically to reduce temporal aliasing (crawling and flickering in motion) through a combination of hardware AA, custom CG film style AA resolve, and a temporal filter.
The Secret World is the first game to support TXAA. Read about it on GeForce.com.
TXAA is supported on GeForce GTX 600-series Kepler-based GPUs.
Learn more about TXAA on GeForce.com.

Performance Boost – Increases performance for GeForce 400/500/600 Series GPUs in several PC games vs. GeForce 301.42 WHQL-certified drivers. Results will vary depending on your GPU and system configuration:
[...]

Maybe they are trying to fix your code desperately - I could imagine things like "well he uses a sucky SDK version in that call - LET US FIX THAT" .
added on the 2012-10-20 00:17:11 by las las
yeah but the point is the crash can happen before the imports are even finished, meaning before your entry point is even reached.
added on the 2012-10-20 00:24:43 by Gargaj Gargaj
Maybe they hook into LoadLibrary and modifiy microsoft dx-dlls on the fly, in memory. What could possibly go wrong. Btw. googled a bit around there are tons of gamers complaining about > 301.42 drivers, mentioning rollbacks all the time.

Those damn changelogs should be much more verbose. I could also image that there is a random setting in the NV controlpanel that "fixes" the problem.
added on the 2012-10-20 00:55:28 by las las
Okay. I just had a short look at the driver installers - and the *wrap*.dl_ files looked kinda suspicious... After some searching...
This thing might be worth a further look: The "coprocmanager" directory + detoured.dll -> http://research.microsoft.com/en-us/projects/detours/

Quote:

Detours is a library for instrumenting arbitrary Win32 functions Windows-compatible processors. Detours intercepts Win32 functions by re-writing the in-memory code for target functions. The Detours package also contains utilities to attach arbitrary DLLs and data segments (called payloads) to any Win32 binary.


Let me put it this way: I've seen enough hentai to see where this is going.
I'm still desperately trying to get my system to crash ;)
added on the 2012-10-20 01:50:49 by las las
Yeah, see, that's the library kkapture uses :P
added on the 2012-10-20 02:01:15 by Gargaj Gargaj
Downloaded detours express 3.0 - straight from the readme:
Quote:

4.4. COMPATIBILITY IMPROVEMENTS:
================================
Fixes have been made in Detours 3.0 to improve support for target binaries
containing no DLL imports, DLL binaries compiled for online-patching,
binaries generated with hot-patching support, and 64-bit PE binaries
containing managed code.


Now guess what - straight from my coprocmanager/detoured.dll
Quote:
T:\sw\tools\SDK\detours2.1\bin\winxp_x64_release\detoured.pdb


Well. That's not version 3.0. So *caught* there might be problems with binaries containing "no DLL imports"...
added on the 2012-10-20 02:04:49 by las las
-t.
Good morning pouet.
added on the 2012-10-20 11:09:39 by las las
Quote:

[HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\CoprocManager]
"OptimusEnhancements"=dword:00000001


Could somebody with "crashing" system set that key to 0, try, if it does not work - reboot and try again? If it still does not work, just set it to 1 again...
added on the 2012-10-20 18:31:32 by las las
Still BEX exception crash here with that registry change. [yes, after reboot]

Thanks for messing around with this, by the way!
added on the 2012-10-20 21:32:32 by micksam7 micksam7
Damn it.

Could you try to replace the files in:
Code:C:\Program Files (x86)\NVIDIA Corporation\coprocmanager


With those from
Code:C:\NVIDIA\DisplayDriver\301.42\WinVista_Win7_64\English\Display.Driver

- you first need to expand those *.dl_ files using:
Code: expand -R *.dl_

The extracted files have the ending .dl - you need to change that to dll.

Try to replace these with the older extracted versions from 301.42.
Code: detoured.dll (actually I don't think you have to replace this one, do it anyways) Nvd3d9wrap.dll nvdxgiwrap.dll


But well. This could screw things up horribly - but I would give it a shot, do backups of the old files. And we are not sure whether this helps or not.
If you are not sure whether you can fix things yourself if something goes wrong - don't do it.
added on the 2012-10-20 21:55:05 by las las
(And we are pretty sure it is some kind of NV Optimus thing - yes - also on Desktops).
added on the 2012-10-20 22:00:05 by las las
No volunteers?
added on the 2012-10-22 11:29:23 by las las
Update from trsac: we didn't really get any further, as we only had blueberrys laptop that could fail, and it didn't after going back to the R304 drivers (from the older, working set)...
added on the 2012-10-22 11:40:27 by Psycho Psycho
Well - you should give the wall of text I left behind a read - I think it's some detours problem on optimus. :)
Given that nobody in mercury buys broken hardware - we don't have any failing configurations.
added on the 2012-10-22 12:48:59 by las las
Same issues with the new R310 family of drivers (310.33).
added on the 2012-10-23 20:15:59 by vampire7 vampire7
Replacing nvd3d9wrap.dll with the one from 296 makes things start, but veery slow and sometimes just black - also slower than I would expect from the hd3000, so something completely borked there. And dx11 stuff can't open the device.

Found a detoured.dll 3.0 somewhere?
added on the 2012-10-23 21:27:12 by Psycho Psycho

login