pouët.net

detoured.dll is just a dummy DLL created by the detoured framework - in order to make it easy for microsoft to detect it (microsoft does not support anything using detoured - I really would like to know what NV had to pay for the WHQL certificate....).

Psycho: Is your system a Desktop? Could you try to disable the intel graphics via some BIOS setting in order to "defuse" optimus?

Next thing somebody with the crinkler sourcecode could try (HINT HINT): Add one import and see if stuff works, if it does - then we are sure about who to blame - and for what.

When nvinit.dll is loaded dynamically and an exception occurs during initialisation (for example, while acquiring the address of NvOptimusEnablement from a host image with invalid AddressOfNames pointer in the export table - Crinker produces files that demonstrate this), then the DLL is unloaded but leaving a FLS pointer behind, and the process continues to execute.
This pointer is called during process termination, usually resulting in a crash, but depending on the host process, unexpected behaviour might occur.

Quick solution: remove the reference to nvinit.dll from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

"When nvinit.dll is loaded dynamically and an exception occurs during initialization" - from what I saw and iirc - nvinit.dll starts the whole detouring stuff - so it most probably happens in some routine responsible for that - does it?

Does defusing that stuff via disabling nvinit.dll AppInit impact performance/functionality?

Removing the appinit_dlls key didn't change anything on the laptop, and it's already empty here on the desktop.. (and right now ikanim2012 works on the desktop, but crinkler crashes on the laptop, while elevated still crashes on both .. problem seems kinda random)
las: laptop, can't disable optimus / intel gfx.

What about those intros that used import-by-hash before crinkler?

The problem is not import-by-hash, it's export directory (seemingly) containing invalid data. The nvinit.dll just calls GetProcAddress and hopes for the best. There is no exception handling around it. An exception causes the DLL to unload unexpectedly, with obvious bad results.
btw for 64-bit systems, the reg key is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
Don't delete the key, just rename the nvinit.dll -> nvinit.dll1 or something.
It's not a proper solution, but it stops at least some of the crashes (though you might lose some functionality for well-formed progams - you can always change it back using .reg files).

Nice to have a working solution (well at least somewhat of an workaround)! Thank you for taking your time on that issue. :)

It's still seems to be an Optimus only problem - right?

Let's consider this fix "works" - and look at Optimus: Which graphics device would one get at 3D API context setup? From the *wrap* dlls I took a rough look at I would say these - used by nvinit - are responsible for giving you the NV device rather than the Intel.

I might be mistaken there, but if the fix turns out to force you to the Intel device - it's rather useless - at least for newer productions.

Another thing - where do they do that "device-switching-stuff" with OpenGL?

On my crashy desktop pc both keys are empty. jsyk :)

zoom, that simply shows that there is more than one issue. Too bad for us.

As far as the nvinit fix goes, it does not force use of the Intel device. After applying the fix, I can still run demos that work only on the nVidia device. The other nVidia DLLs are still being loaded.

Yeah, removing it from the wow6432 indeed stops the crashes, but also means that I'm intel only on the optimus laptop ;) The gtx570 machine has both regkeys empty, but IS also running more stuff - elevated still crashes though.

qkumba, since you seem to know the issue from elsewhere, and thereby other implications than crinkler.. What are the chances of nvidia fixing their stuff (ie how serious is the problem for them / the world).

qkumba mentioned this is not the case, I suspected this to be happening - now what is the truth?

Well crinkler binaries are not the standard use case - but crashes similar to that seem to be happening not only with crinkler like binaries - so we might be lucky.

My current thoughts regarding this whole issue: You guys at NVIDIA screwed up horribly.

Another thing we still have to figure out: Is OpenGL for any strange reason NOT AFFECTED? - That would be wonderful - I'll provide a testing binary which wont work without OpenGL 4.2 asap.

this one should do the job
It's using #version 400 shaders and glCreateShaderProgramv (which is not supported by Intel - I hope). If it does not crash - and works - you might have to press ESC for a while to make it quit - lazy code.

So this will crash either in case you get the Intel Device (currently not supporting GL_ARB_separate_shader_objects thus no glCreateShaderProgramv) or in case some random NV Driver fun happens.

It needs at least OpenGL 4.1 iirc, so be sure you have support for that on your given NV card (well you should have support for that... otherwise I don't think you would mind reading this thread).

Zoom: Please tell me that this works on your machine - which seems to be the "worst case machine".

las: that one works, but didn't we already rule out opengl with lunaquatic?

lunaquatic also could have been running with older OpenGL on Intel.
I wanted to be sure - this is actually quite good news for me. Thank you for testing.

on that note, anyone tried 4k's under win8?

hey, is this a good place to ask what I need to install in order to run 4k's with Windows 7? I just got a new computer without knowing anything about Windows world, and both cdak and elevated APPCRASH.

dxdiag says it has DirectX 11 installed, I downloaded the DirectX redistributables linked earlier in this thread but the installer doesn't tell me where to put them.

i'm running 306.97 drivers but i don't know if i'm supposed to install other stuff before blaming them.

Optimus might well be disabled by disabling the nvinit.dll, since that DLL is the one that's querying for the support in the host process. I didn't intend to suggest that it's still enabled - I don't know that, I haven't tested it.

However, nVidia people do seem to have screwed up this update.

As far as how I found out the cause of the crashes on my system - I reverse-engineered the DLL. It's not like I work for nVidia or have insider knowledge.

OpenGL is not affected because the crashing code path is not taken, but it has not been interesting to me to find out why. I don't care why something is *not* crashing. ;-)

@fosforgrim this thread is about that very crashing issue under windows and the R300 series drivers from Nvidia, trying to determine exactly what is going wrong and where.

OK, so I don't have to install anything else before trying to run those demos?

(sorry, I don't know anything about Windows or which libraries are considered standard for demo making).

fosforgrim: You will need the DirectX End-User Runtime, not the redistributable.

Furthermore, for 4k intros compressed using a Crinkler version before 1.2 (roughly 2009 and before), you need to run them through Crinkler /RECOMPRESS to make them Windows 7 compatible.

If you don't want to run Crinkler yourself to recompress, I have made a collection of patches available from my site (http://pferrie.host22.com/misc/dosbox.htm) for the demos that I know are broken.

Thanks a lot for the help, both run fine after downloading the end-user runtime!
(& a Windows 7 compatible version in the case of elevated)

4ks seem to run fine on win8 (dunno about win8+nvidia..), just a little funny that you need to install the jun2010 dx runtimes..

Gargaj: After I fixed crinkler (/RECOMPRESS) and installed directx runtime, everything went fine. I tried 4 of them: elevated, kindernoiser, luxo4k and chaos theory 4k remix. Nvidia GTS450, driver version: 306.97, Win8 64 bit.