Jump to content
  • Advertisement
Sign in to follow this  
pseudomarvin

How to find the source of a crash that happens in a igd10iumd32.dll

This topic is 964 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

Every once in a while (let's say in 10 % of cases) my program crashes on startup, possibly while loading textures or during some other initial operation with the GPU, in the igd10iumd32.dll (which is the intel graphics driver library). The problem is that VS2015 does not show the call stack in this case and only reports that the error ocurred in the aforementioned DLL. What is the most reasonable way of debugging this? I could strategically place breakpoint across my code to try to isolate the part of it which is responsible but that means restarting the program and waiting for the bug to occur. Maybe there is a better way? Thanks.

Share this post


Link to post
Share on other sites
Advertisement

Check you exception settings (Ctrl + Alt + E) and mark all of them, this should help the callstack problem.

Other wise the only option I see is to step trought the program or to execute the API with every single(or potetial) peice of data? and see where it breaks or if there is any pattern.

Share this post


Link to post
Share on other sites

The best way to start debugging it is to get that crash up from 10% of the time to all of the time.  What's different between the runs when it crashes and the runs when it doesn't?  Ensure that you have the same data sets each time, identify transient conditions on your PC, whatever else may be happening.  Once you get the crash reliably reproducable your knowledge of what was different will help you identify where to start looking for causes.

Share this post


Link to post
Share on other sites

I've set the exception settings to most stringent but VS still cannot detect where the DLL code was called from. So I will have to take the more thorough debugging path. Making the crash reproducable every time is a great idea but since the code base is not that large and I have no idea what the conditions for it to occur are I will just try to debug the code step by step and see where it happens. Thank you both.

Share this post


Link to post
Share on other sites

BTW do you have d3d11 debug Layers enabled? If you are using d3d API the wroing way it is quite possible to recieve a good explanation.

Reascently I've created a memory corruption using Buffer Map/Unmap.

Another idea to debug this is to bisect the code versions , try to find the 1st revision that has this problem and double check the changes from that commit.

Edited by imoogiBG

Share this post


Link to post
Share on other sites

I do have the D3D11 debug layer enabled but it does not report any misbehavior before the crash so it probably has not detected it. Bisecting the code revisions is good suggestion. Thanks again.

Share this post


Link to post
Share on other sites

In case anyone with a similar problem is reading this: I ended up putting a debug print with a unique content at the beginning of each graphics related function that was a suspect(e.g.: "InitModel() is being called for the %d th time.", cnt++). That way when the crash occured I could tell which function was the last to be called and consequently is responsible for it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!