[REGRESSION] wined3d crashes when running dxdiag tests -> Fixed in SVN.

Can't reproduce with 1.1.19 build which just doesn't work the same way as it was in the very beginning regardless of additions version. Calling null pointer returned by getprocadress for some arb extension.

Though indeed there's regression for 1.1.18.

Hi Leonid,

Thanks for looking into this!

Replying to leonid:

Can't reproduce with 1.1.19 build

Just to rule out possible differences, are you using the build from http://www.nongnu.org/wined3d/ or did you build it yourself?

which just doesn't work the same way as it was in the very beginning regardless of additions version. Calling null pointer returned by getprocadress for some arb extension.

Yes, this was fixed in official Wine. My 1.1.19 build is from their pristine source.

Though indeed there's regression for 1.1.18.

You mean official 1.1.18? It should work with a small patch:

http://download.savannah.nongnu.org/releases/wined3d/1.1.18/patches/baskanov_1.diff

(this patch is already included in my 1.1.18 builds)

Btw, perhaps the problem is dependant on host OpenGL. Mine is:

OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 945G 20061017 OpenGL version string: 1.3 Mesa 7.0.4

Yes, I was using builds from the page you've mentioned on winxp32 sp2 guest with winxp32 sp3/ubuntu32/ubuntu64 hosts and ATI 4850, NV quadro fx3700 GPUs. Installing only d3d 8-9 parts.

Regression with 1.1.18 fixed in svn.

Note that vendor string passthrough patch isn't applied to our code base yet.

Note further that this fix is too intrusive to get into the next maintenance release.

Replying to frank:

Note further that this fix is too intrusive to get into the next maintenance release.

Oh, that's a pity. Can we find some way to work around it in WineD3D?

Looking at the commit message / diff it seems to be a multithreading issue. Can you provide more details on the nature of the problem? Perhaps we can solve it by making WineD3D enter a critical region in the appropiate section?

And I'm still not sure we found the same regression. Mine is found with wined3d 1.1.19 on Intel 945G, yours in 1.1.18. Could this be a race condition affecting both versions?

Btw, I've run into threading problems with vboxogl.dll before (NtCurrentTeb?()->glTable is corrupted by vboxogl.dll when using ReactOS' opengl32.dll, see http://www.reactos.org/bugzilla/show_bug.cgi?id=4385 for details). I wonder if they're related.

Are the issues in this bug being worked on in a branch that I could build and test?

Now that 2.2.2 has been released, is that a target release for this fix?

BTW How can I add myself as CC to a ticket?

We cannot guarantee any ETA for the next major release, sorry. The expected range is a few months. You should already receive E-mails from this ticket as you posted a comment. If you don't, please check your E-mail settings.

Please try it with v3.0.0 again.

Does anyone have a list of DirectX files they have in their system32 folder that I can use as reference? This Windows XP. I need this to make sure that I don't have any unnecessary DX files that could be causing other crashes.

WinXP64bit_System32_DirectX

Replying to MrX1980:

Please try it with v3.0.0 again.

Please read the manual and release notes. Same applies to another ticket(3541) which you've commented on. 64bit windows guests are *NOT* supported.

Even if 64-bit is not supported, at least the screen shot gives me an idea of which Direct-X files I should have in my folder, if indeed the tests run successfully in dxdiag. I hadn't been able to get that from anyone else.

I am using using Windows XP 32-bit on MacOS X.

Please upgrade to VBox 3.1.0, upgrade the guest additions to 3.1.0 as well! Does the problem persist?

Works with 3.1.0 here.

Host: Windows XP SP2, 32-bit, Core 2 E8400, VBox 3.1.0, VT-x=off.

Guest: Windows XP SP2, 32-bit

-Technologov

Please reopen if someone experiences this problem with VBox 3.1.0 (make sure to upgrade the guest additions to 3.1.0 as well!)