Sign in to follow this  

Debug Runtime: computer hang-up

This topic is 4330 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, i've got some weird troubles with the DirectX debug runtime. Whenever I switch from retail to debug, some strange things happen: 1) In my application: when a dirct3d error occurs, no message is displayed in debug output but the computer simply restarts. 2) OR: I get a memory error when calling CreateWindowEx. 3) Every directx application quits with a similar memory error: the samples from the sdk, my games and my own application. Some information about my system: Radeon 9800 XT with Omega drivers DirectX SDK and both runtimes from April 2005 Windows XP, Visual Studio 2005 Express Can anybody explain these symptoms? Should I install a newer SDK? I haven't tried yet because I don't want to download 310MB if there is an easier way to solve my problem. Tell me if you need any additional information. Tubos [Edited by - Tubos on January 27, 2006 6:05:21 PM]

Share this post


Link to post
Share on other sites
No.

I had Omega Drivers 2.6, but the current version is 3.8 ;)
I've downloaded them immediately, and installed them after uninstalling the old drivers.
The new version is great, performance is much better.

But this hasn't solved my problem.
Still, when my program tries to execute a wrong DrawPrimitive call, the computer simply restarts instead of outputing the debug info.

Share this post


Link to post
Share on other sites
I've now downloaded and installed the latest DX SDK.
But my problem still occurs.

Do I have to link to the debug libraries?
Any other ideas?

Tubos

Share this post


Link to post
Share on other sites
hi there,

Hmmm..first of all...did you compile your application as Debug or just a Release version of it?

While in Debug...just step through your DX initialisation routines to locate where the program crashes.
- Did you link the Direct3D debug versions of the libraries?
- Is it always the same DrawPrimitive call or does this error occur occasionally?

hope this helps!
best regards,
- christoph -

Share this post


Link to post
Share on other sites
> did you compile your application as Debug or just a Release version of it?
I always use debug for development.

> Did you link the Direct3D debug versions of the libraries?
Yes, I link to d3dx9d.lib.
The other libraries have no debug versions. Am I right?


I've switched back to Visual Studio 2003, and now the Debugging works. I can see the debug info from DirectX, and when I make a wrong call, DX interrupts my application and I can see the error message.

But I've got just one more strange problem: One vertexbuffer->Unlock() call seams to be wrong, and instead of breaking, I get an access violation.

Any ideas concerning this problem?

EDIT:
Ok, it was my fault. I've overwritten more than the locked area.

Thanks for help!
Finally, I can continue programming :-)

[Edited by - Tubos on February 4, 2006 9:38:40 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Tubos
EDIT:
Ok, it was my fault. I've overwritten more than the locked area.

Aha! You have discovered a cardinal sin of D3D...if you want a one-way ticket to constant reboots, just do some naughty things with buffer pointers. I'm not quite so sure why it's so bad, but it is certainly a driver-level problem when it happens.

Share this post


Link to post
Share on other sites
Quote:
Original post by circlesoft
Aha! You have discovered a cardinal sin of D3D...if you want a one-way ticket to constant reboots, just do some naughty things with buffer pointers. I'm not quite so sure why it's so bad, but it is certainly a driver-level problem when it happens.

My understanding is that it's not a regular pointer. Normal 32bit/Win32 pointers can address 4GB of memory - but that doesn't include the VRAM.

Thus you have a "staging area" of sorts that is addressable via the CPU and GPU (albeit, with some driver intervension). The exact mechanics are unknown to me (or anyone?), but it's not normal RAM. You're returned a pointer to a piece of memory that you can write to (from the CPU) and that the GPU (and/or driver) can upload to it's local VRAM.

It's for this reason why it seems that you can get the same pointer for multiple independent Lock() calls. Check it out via the debug sometime [wink]

As a general point, the OS will stamp on you if you write out-of-bounds, especially in the current world of security-conscious operating systems. In this case, where you're talking about "fragile" memory between kernel mode OS and drivers and user mode applications and physically seperate hardware it's a lot easier to really mess things up [oh]

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Thus you have a "staging area" of sorts that is addressable via the CPU and GPU (albeit, with some driver intervension). The exact mechanics are unknown to me (or anyone?), but it's not normal RAM. You're returned a pointer to a piece of memory that you can write to (from the CPU) and that the GPU (and/or driver) can upload to it's local VRAM.

Aha that makes sense...the other week, I was new'ing a locked pointer (don't ask, it wasn't very simple [grin]). Suffice it to say, it only took me a few reboots to find it [wink]

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
The exact mechanics are unknown to me (or anyone?), but it's not normal RAM. You're returned a pointer to a piece of memory that you can write to (from the CPU) and that the GPU (and/or driver) can upload to it's local VRAM.


Locked vertex buffers will quite often be in AGP memory. Thus today this post is sponsored by the acronym GART.

GART = Graphics Address Re-mapping Table

And here's something someone else prepared earlier [smile]: http://www.intel.com/cd/ids/developer/asmo-na/eng/20410.htm?page=1

With local video memory (on card rather than AGP or UMA), similar stuff goes on, but there's a lot more vendor specific magic such as what goes on with 3DLabs' virtual texturing.


To get more context it's probably also worth understanding a little about how virtual memory works on x86 platforms (i.e. the difference between real and protected mode and the meanings of a few key acronyms: TLB, and PAE).


Deliberate over simplification: Touching addresses of a page outside of the mapped range of addresses gives you a page fault; if that page isn't known about by the virtual memory system or any other interested parties (device drivers etc), you get a page fault exception; if the exception isn't handled by the program which caused it, and the environment is ring3/user mode, you'll get a message box from Windows and the program terminated; if the environment is ring0/kernel mode (inside a driver or the kernel) or Windows isn't playing nice that day, you'll get a blue screen/reset. Sometimes the difference between a handlable exception and a BSOD when you access outside of a locked buffer is dependent on how nicely the device driver copes with 'unexpected' things.

Share this post


Link to post
Share on other sites
Quote:
Original post by S1CA
... Thus today this post is sponsored by ...


And here's something someone else prepared earlier ...
It's like Sesame Street and Blue Peter rolled into one [lol]

That Intel link was pretty interesting, I'll have to bookmark that.

Cheers,
Jack

Share this post


Link to post
Share on other sites
Quote:
when my program tries to execute a wrong DrawPrimitive call, the computer simply restarts instead of outputing the debug info.


Scary! So much for OS stability. Imagine back in the day when any access violation could potentially crash the system not just the app. No chance to debug, just POOF!

Share this post


Link to post
Share on other sites

This topic is 4330 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this