SlimDX with DirectX11 crashes when trying to debug with GPUPerfStudio 2.8

[GoogleCodeExporter]

Hi there, 

I have been trying to profile / debug my SlimDX applications using 
GPUPerfStudio - with no success. All the applications (Including the DirectX11 
Samples provided with SlimDX) crash when GPUPerfStudio tries to capture a 
frame. 

Here is a Stacktrace from the MiniTri11 sample:

Unbehandelte Ausnahme: System.AccessViolationException: Es wurde versucht, im 
geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis 
darauf, dass anderer Spei
cher beschädigt ist.
   bei SlimDX.DXGI.SwapChain.Present(Int32 syncInterval, PresentFlags flags)
   bei MiniTri.Program.<>c__DisplayClass3.<Main>b__2()
   bei SlimDX.Windows.MessagePump.IdleHandler.OnIdle(Object sender, EventArgs e)
   bei System.Windows.Forms.Application.ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FDoIdle(Int32 grfidlef)
   bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvL
oopData)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   bei System.Windows.Forms.Application.Run(Form mainForm)
   bei SlimDX.Windows.MessagePump.Run(Form form, MainLoop mainLoop)
   bei MiniTri.Program.Main()

German Windows - but I guess it's still understandable.

Are there any workarounds or fixes?

Thanks.

Original issue reported on code.google.com by R.Jebens...@googlemail.com on 31 Jan 2012 at 6:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I forgot to mention that the DX10 Samples provided with SlimDX are working fine.
The DX11 c++ samples provided with the DX SDK are also working.

Original comment by R.Jebens...@googlemail.com on 31 Jan 2012 at 6:15

[GoogleCodeExporter]

I'd say it's a bug in your driver or in GPU PerfStudio. The SwapChain.Present 
call is a simple wrapper in SlimDX, about as simple as they come in fact. The 
only way it could cause an access violation is if something wacky was going on 
under the covers, independent from SlimDX.

The reason the native samples are working is probably because they do a lot of 
extra setup work choosing adapters and such. Make sure you've initialized your 
device with the right adapter to work with PerfStudio.

Original comment by Mike.Popoloski on 12 Mar 2012 at 11:42

• Changed state: Invalid

[GoogleCodeExporter]

Getting the same error - when fiddling with different ways of creating the 
device i can get rid of that specific error and instead get GPU Perfstudio to 
get stuck on "connecting..." when clicking "capture frame". 
DX10 sample is working great. I've been laborating with the MiniTri11 
trunk@2182 version.
Seems that if you google some ppl have similar issues with slimdx and nvidias 
parallell nSight. 

You developers must have *some* clue to what might be an issue here? I've also 
tried to do an 1:1 slimdx version of the simple triangle demo from dx sdk.. 
Same behaviour...

Would be great to actually get these really powerful tools to work with 
slimdx...

Original comment by wor...@gmail.com on 4 Apr 2012 at 5:55

[GoogleCodeExporter]

I just tried the VS11 beta, which comes with an integrated Graphics Debugger 
(Pix of some sort). It has the same issue, crashes in SwapChain::Present.

Would be really great if someone could look into this!

Original comment by R.Jebens...@googlemail.com on 4 Apr 2012 at 6:02

[GoogleCodeExporter]

I've verified the same issues with nVidia Parallell nSight now..

Original comment by wor...@gmail.com on 4 Apr 2012 at 9:19

[GoogleCodeExporter]

I'll look into and see if I can repro the issue.

Original comment by Mike.Popoloski on 4 Apr 2012 at 10:26

• Changed state: New

[GoogleCodeExporter]

Much appreciated. From what i've read and seen both are extremly powerful tools

Original comment by wor...@gmail.com on 4 Apr 2012 at 11:31

[GoogleCodeExporter]

This is probably the DX Debug Output regarding the error..

"[5864] CDXGISwapChain::GetBuffer: iBuffer must be zero if swap effect is not 
DXGI_SWAP_EFFECT_SEQUENTIAL
"

Original comment by wor...@gmail.com on 12 Apr 2012 at 10:10

[GoogleCodeExporter]

And when trying with DXGI_SWAP_EFFECT_SEQUENTIAL just for kicks, this is what i 
get:
"[8036] CDXGISwapChain::GetBuffer: iBuffer is larger than actual number of  
buffers
"

Don't know if this gives you any pointers. Hopefully it does :)

Original comment by wor...@gmail.com on 12 Apr 2012 at 10:16

[GoogleCodeExporter]

I just realized today that there's no way I'm going to be able to test this, 
since I have a NVIDIA card.

For Parallel NSight, I see a few threads from the NVIDIA developers mentioning 
that they're still working on managed support. There's a thread on GDNet 
showing that at least some stuff does work: 
http://www.gamedev.net/topic/586494-slimdx-some-slimdx-samples-are-not-debuggabl
e-with-the-nvidia-nsight-debugger/

I'll try some of the samples out using the new VS11 graphics debugger now that 
I have that installed. For the other tools, I'm afraid it's just a matter of 
trying to make it work and filing bugs with their official support teams if you 
can't get it working.

Original comment by Mike.Popoloski on 5 May 2012 at 4:17

[GoogleCodeExporter]

Unfortunately it looks like the VS11 graphics debugger doesn't like managed 
code either. I found a few threads online that seem to confirm that this might 
be a beta-only limitation. I suggest bugging Microsoft as much as possible to 
get them to fix this up, but I wouldn't hold my breath. They never bothered to 
fix the PIX x64 issue with managed code either.

Original comment by Mike.Popoloski on 5 May 2012 at 4:34

• Changed state: Invalid