4k Crash/BEX Issues
category: code [glöplog]
It really seems like a hw/driver combination issue. (GTX260 here.)
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?
GTX580 on 306.63 here - as mentioned before - working properly too.
Other reports of - maybe the same problem:
=> Lunaquatic works - and that one is OpenGL. So it might be a DirectX(9?)/Hardware/Driver/Software combination issue.
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.
Zoom: could you try a crinkler /RECOMPRESS version of lunaquatic.
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.
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.
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.
Let's see how the lunaquatic test turns out. Than it might be some kind of DX support issue.
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:
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
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..
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..
That one says "DirectX 11" and quits normally.
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
texas - dx10
traskogen - dx11
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)
yeah.. texas (after /recompress) opens black screen here and crashes in ntdll. Unlike the dx9 things that crash right away.
psycho: can you step-debug it to see what exactly breaks?
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.
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.
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.
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.
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.
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..
It's on the laptop and also happening when telling optimus to use the intel graphics - iow before it really starts creating the device..
psycho: did you try just a vanilla "void main() { Direct3dCreate9(D3D_SDK_VERSION); }"?
Almost..
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 :)
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 :)
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...
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...
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.
Wait.
vs.
...are we talking about the same crash here...?
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...?
Dunno if the NVS laptop is running optimus
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?
Here on the gtx570 desktop it is crashing in CreateDevice instead, but otherwise looks similar (that difference could very well be optimus).