T3D 1.1BETA 1, 2 and 3 BLUE SCREEN OF DOOM! Possibly reflections - RESOLVED

#1 Well, not wanting to discourage you, when it occurred to me my VGA contain transistors with problems. I think the best thing to do is to find out if the card or is not running a game or something graphic than the torque (Sorry my English, google translations :( )

#2 WARNING: Do not shoot on water! * lol * also tried to do what you did and the same thing happened in the first shot has not been any problems, but the second my computer crashed!

#3 Update, if I take the particle trail off the stock missile, I don't get crashes and glitches. I do when I put it back on. (I thought it might have been

Typing through flashing "speckles" here, I turned Aero off and the screen cleared up. However if I restart New_Project.exe, it "and any other T3D project - even older ones" still has the visual glitches.

edit: and after hitting post now it's all back over my desktop again! Rebooting!

edit2: And he's back. A bit more testing and yep, pretty sure it's reflections getting overloaded with particles.

remove the particle trail from the rocket in game/art/datablocks/weapons/rocketlauncher.cs and all problems stop.

datablock ProjectileData(RocketLauncherProjectile)
{
....
//   particleEmitter = RocketProjSmokeTrailEmitter;
//   particleWaterEmitter = RocketTrailWaterEmitter;
....
}

Don't remember this issue in previous versions.

#4 Well Steve I shot a tree from the forest editor with the rocket launcher projectile and it crashed my game completely out :/

#5 @Jesse
See if you can call a stack from a debug version.

I've been shooting trees okay ... save for the already reported collision detection issue linky.

#6 Sorry to say, but I've not got any problems here, and I know I've got driver bugs as my graphics card crashed hard last night. It really looks like what I was having happen last night when watching a video just before my graphics card crashed. Though I am having a problem with the ripple decal after shooting at the water remaining there for quite some time.

I'm currently running the RC version of Windows 7 with a 9800GTX so that could be the difference as different graphics card react differently to driver bugs.

EDIT: Okay, just did more testing of this, and the first half-dozen shots across the water had no ill effect, but at some point right after firing across a particularly large body of water T3D crashed, so there is definitely something up.

#7 @ Bryan
Yeah, usually takes a couple of shots for me to trigger the crash.

See if you can call a stack, I get a BSOD when running a debug from VS2008 on this issue so can't get feedback.

#8 Shooting the gun has caused a few random screenfuls o' gray stuff in 1.1 alpha. Thinking back to these incidents, I do believe that I was shooting downwards at ~45 degree angle at a large waterblock.

I had been thinking it was the gun, but because I could not replicate the issue reliably, I was waiting until some pattern emerged to report it.

#9 In my experience I've seen this sort of stuff can be caused by two things:

1) Malformed vertex/index buffers or...
2) Bugged depth/stencil buffers (either invalid buffers or simply having a depth buffer with different sizes than the current render target).

These can cause undefined behaviors which vary across video cards and driver versions. I've seen:

1) Nothing happens;
2) You get bugged geometry somewhere (vertices going off into infinity) depending on camera angle and/or time;
3) Game crashes;
4) The OS goes BSOD;
5) The GPU goes into a hard lock (everything freezes, screen corrupts sometimes).

Anyone getting this should always run T3D while recording a journal: create a shortcut and add this to the parameters:

-jSave debug.jrn

This way you'll be able to playback what you did when you got a crash.

#10 @Manoel
Journal? Is that the same as recording a demo with the F3 function?

#11 Nope, the journal is much deeper than the demo function. It records all input, timing and networking events. It is intended to record a complete session from EXe startup and is not suited for recording demos (recording/playing from mid-execution is bound to cause weird effects).

The console functions are saveJournal(filename) and playJournal(filename). You can tell torque to record by passing -jSave as an argument when running the exe:

fpsExample.exe -jSave demo.jrn

This will record everything you do in the file demo.jrn. To playback you do this:

fpsExample.exe -jPlay demo.jrn

Journals are the best way to grab hard-to-reproduce errors. I was tasked with improving them for T3D 1.1 (there were problems in playing journals at a different resolution than the one they were originally recorded with), and I think the improvements made it to the beta.

#12 Nice to hear that journals have been improved upon since TGE. This is actually a particularly easy error to reproduce but I don't really think anyone would want to create a journal to reproduce this bug. I've been trying to trace the problem in a debug build but so far I've found that; first, the problem only seems to arise with large bodies of water; and second, if you don't kill the app immediately it will kill your graphics driver and cause an actual BSOD. I'm willing to go with a bugged depth/stencil/render buffer as this is exactly what happened in one of my dissertation projects (which was also a deferred rendering engine) and it was ungodly difficult to debug and I still attribute to an actual bug in the driver at the time which was exacerbated by the sheer number of buffers I was using (Any one of them could have been malformed, but from what I could tell looking at the code and from the OpenGL error message stack, they weren't).

The easiest way to tell if this is a driver bug or not is to have someone with an ATI card try it, but since ATI cards are notorious at not being able to do deferred shading or handle large numbers of render buffers(More depending on the drivers then the hardware, but my experience with ATI was up to only shortly after AMD bought them out so things may have improved finally. I do know they still don't have full OpenGL support though, so it makes me doubt they've improved anything.), it may simply fail to run at all.

#13 Whoa, that's a bit spooky! (I have a desperate urge to press buttons whilst watching). But works fine on a "dry run".

Is this designed to just let you see what steps you took before a crash/problem? Or is there any extra feedback about that problem I can get?

hypothetically:

If I get my GPU-crash whilst recording the journal, when I playback the journal the GPU-crash will happen again (correct?). Now I can't run a trace from VS2008 because debug crashes to BSOD, so is there any other info available from the journal?

In other words, I know when my crash will occur, but not how to get more info on it.

unrelated but just curious:
Also, I guess you could use this journal playback just like a non-interactive demo too. Is it to be a replacement of the demo recording function (which I've never actually used)?

edit
What Bryan said.

#14 Hey Guys,
Just had the same problem, was in debug while it did it though and I didn't get a BSOD...

Not sure what I need to be looking for though Steve??
It happened when I had Scatter Sky + Cloud Layer and a water block, I was underwater and then shot from under the water towards the sky and that happened instantly...

I had this happen once in 1.1 Alpha also, just seems easily reproducible now with 1.1B...

Testing exactly the same thing again (underwater shot with scatter sky) this time in release version caused a crash or Torque...

Third test back in Debug, exact same thing again (grey pixels everywhere)

Fourth test, without a cloud layer, same thing (pixels) but I managed to get one shot off from a 25 degree angle, but then at around 45 degrees it happened again

Fifth test, this time I used a basic sun and a sky box, Torque crashed but no pixels...

Didn't get any BSOD's though, Win 7, Aero, Nvidia 9600GT, Athlon X2

#15 @Leon
Just incase you don't know - 'cos I didn't until I saw it on the forums - you can get feedback from using a debug by "calling a stack" from running T3D from VisualStudio.
1. Load the project (eg New Project, not the toolbox) into VisualStudio
2. With debug selected from the drop down menu, press the green play arrow next to it.
3. This starts the T3D project exe and records lots of debugging info.
4. When T3D crashes, look for the bit which says stack and find the offending code lines.

I'll have a few more goes to try and get a debug to crash without BSOD - didn't think of swapping scattersky for normal sun.

#16 Hmm excuse me if I am talking rubbish here, but won't the stack info only show when I break the code? I had that info on my last 1.1A showing up and I am sure it was only there when I went to step through the code, not sure now :s (kind of new to C++ yet....)

*Edit* Nope, am talking rubbish I just found the option xD, does the below help at all? the little green arrow is pointing to the occlusion query, not sure what to look for :P

#17 d3d9.dll!564b8471()
[Frames below may be incorrect and/or missing, no symbols loaded for d3d9.dll]
d3d9.dll!564b8ff6()
d3d9.dll!564ba154()
d3d9.dll!563d68cb()
d3d9.dll!56401fed()
d3d9.dll!563d69d3()
> zTest_DEBUG.dll!GFXD3D9OcclusionQuery::getStatus(bool block=true, unsigned int * data=0x00000000) Line 61 + 0x1c bytes C++
zTest_DEBUG.dll!ReflectorBase::calcScore(const ReflectParams & params={...}) Line 132 + 0x33 bytes C++
zTest_DEBUG.dll!PlaneReflector::calcScore(const ReflectParams & params={...}) Line 396 + 0xc bytes C++
zTest_DEBUG.dll!ReflectionManager::update(float timeSlice=1.0000000, const Point2I & resolution={...}, const CameraQuery & query={...}) Line 141 + 0x1e bytes C++
zTest_DEBUG.dll!GuiTSCtrl::onRender(Point2I offset={...}, const RectI & updateRect={...}) Line 250 C++
zTest_DEBUG.dll!EditTSCtrl::onRender(Point2I offset={...}, const RectI & updateRect={...}) Line 183 C++
zTest_DEBUG.dll!GuiControl::renderChildControls(Point2I offset={...}, const RectI & updateRect={...}) Line 193 C++
zTest_DEBUG.dll!GuiControl::onRender(Point2I offset={...}, const RectI & updateRect={...}) Line 67 C++
zTest_DEBUG.dll!GuiCanvas::renderFrame(bool preRenderOnly=false, bool bufferSwap=true) Line 1604 C++
zTest_DEBUG.dll!GuiCanvas::handlePaintEvent(unsigned int did=0) Line 247 C++
zTest_DEBUG.dll!fastdelegate::FastDelegate1<unsigned int,void>::operator()(unsigned int p1=0) Line 990 + 0x1a bytes C++
zTest_DEBUG.dll!Signal<void __cdecl(unsigned int)>::trigger(unsigned int a=0) Line 326 + 0x17 bytes C++
zTest_DEBUG.dll!Journal::Call<Signal<void __cdecl(unsigned int)>,unsigned int>(Signal<void __cdecl(unsigned int)> * obj=0x063c8360, void (unsigned int)* method=0x105dffda, unsigned int a=0) Line 541 + 0xa8 bytes C++
zTest_DEBUG.dll!JournaledSignal<void __cdecl(unsigned int)>::trigger(unsigned int a=0) Line 64 + 0x12 bytes C++
zTest_DEBUG.dll!GuiCanvas::paint() Line 1423 C++
zTest_DEBUG.dll!fastdelegate::FastDelegate0<void>::operator()() Line 905 + 0x16 bytes C++
zTest_DEBUG.dll!Signal<void __cdecl(void)>::trigger() Line 315 + 0x13 bytes C++
zTest_DEBUG.dll!Process::processEvents() Line 78 C++
zTest_DEBUG.dll!StandardMainLoop::doMainLoop() Line 543 + 0x5 bytes C++
zTest_DEBUG.dll!torque_enginetick() Line 103 + 0x5 bytes C++
zTest_DEBUG.dll!TorqueMain(int argc=2, const char * * argv=0x0202c1e0) Line 369 + 0x5 bytes C++
zTest_DEBUG.dll!torque_winmain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * __formal=0x00000000, char * lpszCmdLine=0x005e4f98, HINSTANCE__ * __formal=0x00000000) Line 423 + 0x17 bytes C++
zTest_DEBUG.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpszCmdLine=0x005e4f98, int nCommandShow=1) Line 47 + 0x16 bytes C++
zTest_DEBUG.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C
zTest_DEBUG.exe!WinMainCRTStartup() Line 182 C
kernel32.dll!75213677()
ntdll.dll!775b9d72()
ntdll.dll!775b9d45()

#18 So I turned "Use occlusion query" off and it didn't crash, however now when I am about 2 meters under water and look up, the whole water block turns black, from above where it was showing white secular highlights they are now black, turning back on "Use occlusion Query" doesn't crash, but the secular and underwater colour (below 2 meters) is still black...

I say 2 meters below because if I move towards the surface any, then the water returns to normal colour...

#19 Ah, the occlusion query. That's a DX9 hardware feature to boot, and one that isn't overly used, so I wouldn't be surprised if it can make a GPU go belly up by pressing the wrong buttons and hitting a driver bug.

That NULL pointer being passed to GFXD3D9OcclusionQuery::getStatus() is also something worth looking at.

#20 Sigh ... still can't get a trace --- anyone know what to do if it just locks/freezes but doesn crash?