   [SlimDX] SetTexture failure without Exception?
  I am currently investigating a scenario where content is drawn using incorrect/unexpected texture and/or texture content. The problem is intermittent, which makes troubleshooting much more difficult. Currently the most likely candidate seems to be that SetTexture for some reason seems to not have been executed, resulting in the previously used texture remaining set. The exact same operation succeeds a moment later, so actual textures and their content are fine.I have high-level try/catch blocks, so if SlimDX would have thrown an exception (via CheckHResult) I would have seen it.So, are there other cases where a SetTexture call can fail to succeed/complete, without it being serious enough for SlimDX to throw an exception?What about other result codes, such as WasStillDrawing, would they prevent completion and if so, would they result in an Exception being thrown?Thanks in advance, Fredrik[Edited by - freka586 on May 31, 2010 6:19:48 AM]
  SlimDX calls throw on every failure result unless you disable them using the configuration class.   ;  OK, and all results except Success are counted as failures? Can you imagine any scenario where underlying DirectX calls may return Success when something has gone wrong? Running out of process adress space (OutOfMemory) is for instance not uncommon, so if LockRectangle results in memory allocation (despite being in the Managed pool), perhaps that could be a case of failure?Sorry for being so vague, but troubleshooting based on a two separate occurances of "should never happen" is hard! Issues on a lower level is of course another possibility, as Nvidia Quadro is a common factor for both cases. But I still would like to explore aspects of my code before going down that road..   ;  The SetTexture() call itself is unlikely to fail - the only listed error code in the documentation is D3DERR_INVALIDCALL i.e. you've passed invalid parameters. That's probably because most of the actual work for state setting calls like that is actually deferred to the next draw call.That and that it's only been seen on one video card makes it sounds like a driver issue to me. I'd start by finding out what driver versions are involved, and how old they are.   