pouët.net

Go to bottom

4k Crash/BEX Issues

category: code [glöplog]
It really seems like a hw/driver combination issue. (GTX260 here.)
added on the 2012-10-16 14:35:59 by zoom zoom
So we just have to figure out what we are doing right. Just to be sure - latest DirectX redist with all the fancy d3dx_XX.dll's installed?
added on the 2012-10-16 14:37:26 by las las
GTX580 on 306.63 here - as mentioned before - working properly too.

Other reports of - maybe the same problem:
Quote:

After updating my Nvidia GT540M Win 7 driver from 301.42 to 306.23, nothing works anymore. A reinstall of the old one fixed the problem.


Quote:

I too have many crash with win7 fixed intros (crinkler 1.2 and 1.3). Only one seem to work well after recompress : Lunaquatic.

The issue seems to be an incompatibility with the Geforce R304 driver (from 304.48 to 306.97). The 301.42 is the last one who can properly run crinkler compressed intros.

Any fix planned?

=> Lunaquatic works - and that one is OpenGL. So it might be a DirectX(9?)/Hardware/Driver/Software combination issue.
added on the 2012-10-16 14:45:40 by las las
Zoom: could you try a crinkler /RECOMPRESS version of lunaquatic.
added on the 2012-10-16 14:47:17 by las las
it can't be a hardware problem because we used this card in zoom's box at function and we had it crash either way.

Win7 version maybe? My box (where everything works) is Enterprise 64bit SP1, Zoom's box (where it crashes with newer drivers) is Ultimate 64bit SP1.
added on the 2012-10-16 14:47:31 by Gargaj Gargaj
Win 7 Professional 64Bit SP1 here.
Let's see how the lunaquatic test turns out. Than it might be some kind of DX support issue.
added on the 2012-10-16 14:51:37 by las las
Ok, so...

301.42 still works.

306.23 crashes.

And Lunaquatic works even with the 306 one, so yeah, connected to DX.

http://www.microsoft.com/en-us/download/details.aspx?id=8109 is up.

Crash details:
Code: Problem signature: Problem Event Name: APPCRASH Application Name: elevated_1920x1080_fixed.exe Application Version: 0.0.0.0 Application Timestamp: 38a66ae8 Fault Module Name: ntdll.dll Fault Module Version: 6.1.7601.17725 Fault Module Timestamp: 4ec49b8f Exception Code: c0000005 Exception Offset: 000300e2 OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1038 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
added on the 2012-10-16 14:55:05 by zoom zoom
Ahh... DX9 probably. Thats why it worked here, i probably only tested dx11 or ogl stuff..
elevated test case (and a few other dx9) is crashing here too :)
Try this on nonworking config (dx11): http://www.pouet.net/prod.php?which=57305

... It probably has something todo with app detection, like back in the early days where crinkler exes crashed ati drivers because of garbage in the (iirc) date field in the PE header..
added on the 2012-10-16 15:08:37 by Psycho Psycho
That one says "DirectX 11" and quits normally.
added on the 2012-10-16 15:12:24 by zoom zoom
doh.. you have gtx260 yeah.. And failing to open the device doesn't necessary count as working if the device could open.
texas - dx10
traskogen - dx11
added on the 2012-10-16 15:15:43 by Psycho Psycho
Texas tries to open something but still crashes after some flashing, but that might be due to the missing media files. And the safe version isn't crinkler compressed :) (which runs btw)
added on the 2012-10-16 15:19:40 by zoom zoom
yeah.. texas (after /recompress) opens black screen here and crashes in ntdll. Unlike the dx9 things that crash right away.
added on the 2012-10-16 15:22:40 by Psycho Psycho
psycho: can you step-debug it to see what exactly breaks?
added on the 2012-10-16 15:28:32 by Gargaj Gargaj
Let's consider that texas thing as "it works".

Might it be a nasty hash collision?

Do we have a win7 dx9 compressed intro using /SAFEIMPORT? That might tell us a bit more.

Gargaj already suspected it could be Visual Studio or some SDK coders tend to have installed.
added on the 2012-10-16 15:31:42 by las las
I posted this same issue a while ago and everyone said i'd screwed something up even though i knew i hadn't ;p The R300 series of NVidia drivers does some odd things, like recent ASD demos run but the all the visuals are screwed up.

My C2D + ATI4850 runs stuff fine, both in XP and Win7.
My Ivy Bridge based i5 3570k + Nvidia 670 system spazzes out over 4ks and ASD demos. Up until the 306.97 driver i couldn't even run Square by Still, but now it works fine...other demos ran fine apart from recent ASD ones.

I get the same errors as listed in this thread, both BEX and APPCRASH.

Texas fails, Traskogen works fine fyi.
added on the 2012-10-16 22:04:00 by Intrinsic Intrinsic
Quote:
everyone said i'd screwed something up

Obviously you didn't.
ASD NV enhancement also happens here - but is a completely different issue.
I would really like to debug that stuff in order to track down the problem - but it doesn't happen here - thus I can only speculate.
added on the 2012-10-16 22:40:14 by las las
Crash is happening when calling Direct3dCreate9(), and stack trace is ntdll, nvapi, kernelbase, nvumdshim, kernelbase, nvumdshim...
It's on the laptop and also happening when telling optimus to use the intel graphics - iow before it really starts creating the device..
added on the 2012-10-17 00:40:48 by Psycho Psycho
psycho: did you try just a vanilla "void main() { Direct3dCreate9(D3D_SDK_VERSION); }"?
added on the 2012-10-17 00:46:00 by Gargaj Gargaj
Almost..
Code:void WinMainCRTStartup(){ while (!GetAsyncKeyState(VK_SPACE)); Direct3DCreate9(D3D_SDK_VERSION); }

To make sure it didn't crash before the call... without the loop it somehow doesn't build a valid PE file, but that's unrelated :)
added on the 2012-10-17 01:10:08 by Psycho Psycho
The problem is present on my laptop (i7, NVS 4200M, W7 Pro 64) with 306 drivers, but it works with 295 drivers.

I put a breakpoint at the end of the decompressor by replacing the RET instruction that normally jumps to the decompressed code (pointer having been pushed on the stack earlier on) by an INT3. If you want to try that out, use a hex editor to replace the C3 byte occurring right after 7B AD by CC.

Weirdly enough, it seems that the top of the stack contained garbage for some reason, causing the RET to jump into unknown waters. This means that the crash occurs even before the import code is run (since this is part of the compressed code). So if the crash is dependent on which functions are used in the intro, it is apparently not because they are called or imported, but rather because different imported functions result in different hashes being present in the header (and sometimes in different placement of some of the decompression code).

Need to investigate some more, it seems...
added on the 2012-10-17 01:11:46 by Blueberry Blueberry
now even dx11 stuff crash here.. again I can create the window etc, but then it crash on D3D11CreateDeviceAndSwapChain(). And again with a loop before the call to ensure it's not in the crinkler code or import dependent.
added on the 2012-10-17 01:47:15 by Psycho Psycho
Wait.
Quote:
This means that the crash occurs even before the import code is run

vs.
Quote:
I can create the window etc, but then it crash on D3D11CreateDeviceAndSwapChain()


...are we talking about the same crash here...?
added on the 2012-10-17 01:52:03 by Gargaj Gargaj
Dunno if the NVS laptop is running optimus
added on the 2012-10-17 01:56:07 by Psycho Psycho
so i was thinking about updating my gtx 260 to a 660 (Ti), does that mean I will update to a lot of crashy crinkler-intros?
added on the 2012-10-17 09:23:27 by wysiwtf wysiwtf
Here on the gtx570 desktop it is crashing in CreateDevice instead, but otherwise looks similar (that difference could very well be optimus).
added on the 2012-10-17 10:04:10 by Psycho Psycho

login

Go to top