Access violation writing location 0xCCCCCCCC

Question

So i have one of the wierdest bug i've seen in my life. I've bought a DirectX 11 book which comes with some [sample code]:http://www.d3dcoder.net/d3d11.htm I am pretty sure at some point in time i managed to compile and run every single sample app, but now, i have a "Access violation writing location 0xCCCCCCCC" error at runtime.

Now, this is happening one the following line :

ShadowsApp::ShadowsApp(HINSTANCE hInstance) : D3DApp(hInstance)
{
    mMainWndCaption = L"Shadows Demo"; <- Crashes here !!!  
    mLastMousePos.x = 0;
    mLastMousePos.y = 0;
    ...
}

mMainWndCaption being declared like this in the .h

std::wstring mMainWndCaption;

and set with a default value in the constructor of the class ShadowsApp inherits from

D3DApp::D3DApp(HINSTANCE hInstance) : 
mhAppInst(hInstance),
mMainWndCaption(L"D3D11 Application"),...

I think, this is already quite odd ... Now the strangest part comes when i declare ANY variable of ANY type in the d3dApp.h, I no longer have the "Access violation writing location 0xCCCCCCCC" error, everything builds and run perfectly. As a C# programmer, this makes absolutely no sense to me. How can the declaration of a random variable in a class can "fix" such a thing ?!

Any suggestion would be greatly appreciated :-)

Handcart

By "when i declare ANY variable of ANY type in the ShadowsApp.h" do you mean you declare a member variable for type ShadowsApp? Also which version of MSVC are you using? (I'm assuming you're using Visual Studio as this is a directx project) – Drivein

yes, say : int foo; boom it works ... – Handcart

Is there more context for this? Where is the problematic instance constructed? – Melinamelinda

Well it's pretty much the begining of the app : int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE prevInstance, PSTR cmdLine, int showCmd) { ShadowsApp theApp(hInstance); if( !theApp.Init() ) return 0; return theApp.Run(); } – Handcart

It's possible your code is scribbling on random memory and creating a "sacrificial variable" causes the scribble to be on that variable rather than mMainWndCaption's internal pointer. – Loy

Woops, sorry i answered a bit too fast, the dummy declaration i have to make to "fix" the crash has to be made in d3dApp.h (the base class) not in ShadowMap.h. I'm running VS2012. – Handcart

@DavidSchwartz I really hope it's not the case, because i have no idea how to investigate such thing. Any article explaining this kind of issues you could share ? – Handcart

That is more than likely not the real cause of the problem. The memory overwrite is caused in another place and this variable declaration just happens to be where the OS stops the program from running (i.e. where the crash is). – Inhale

This is caused because you are using an un-initialized pointer. Increase the warning level of your compiler and treat all warnings as errors. The compiler will then tell you were the error is. – Paleontology

How do you instantiating your class? Does ShadowsApp inherits publicly from D3DApp? – Injunction

0xCCCCCCCC is uninitialized memory When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete? – Horselaugh

Answer 1

This page has a good description and background of the various "magic values" you might encounter when dealing with stack and heap.

From the page:

If you are seeing the 0xcccccccc bit pattern it means that you are reading memory that is on the current thread stack that has not been initialised.

Given the code snippet you've posted so far, and what you've described about "fixing" it with another variable declared in the base class, it sounds like the base and derived objects might not be in agreement as to their memory layout. Are they in the same library or executable? Check your compilation flags and make sure they match.

One strategy is to reduce your problem down to the minimal set of steps to reproduce the problem. You can make a copy of your project and start removing fields and methods until it works, and see if that helps you isolate it further.

Serra

Thanks for the suggestion ! Yes, my solution only has one .vcxproj which contains all .cpp and .h. So as far as i know, they should both end up in the same binary. I actually though about reducing the size of my app to the minimum to isolate the issue, but i was hoping i would not have to ;-) Looks like i don't have a choice if i wanna know what's really going on here... – Handcart

Answer 2

"Access violation writing location 0xCCCCCCCC" error at runtime.

You're trying to use unitialized pointer under msvc in debug build.

Initialize pointer.

mMainWndCaption = L"Shadows Demo"; <- Crashes here !!!

Install breakpoint at this location, run application under debugger, and investigate contents of variables (within "watch" window, or by hovering mouse over individual variables), including this pointers.

Extraordinary

Well if i do that, mMainWndCaption contains the default string it got from the base class constructor : "D3D11 Application". – Handcart

@Handcart What about the this ptr? – Drivein

@Yann: In this case make sure that you actually CAN assign new values to mMainWndCaption and that you shouldn't pass caption as a parameter into constructor. If I remember correctly, D3DApp is a sample class written by microsoft to be used in DXSDK. So I wouldn't be surprised if assigning new value to it would do something weird. – Extraordinary

@Drivein I am not exactly sure what you mean by "what about the this ptr" but, it looks ok to me : i.imgur.com/XKk6ikF.png – Handcart

@Extraordinary Well in my case, D3DApp is a class written completely from scratch by the writer of the book i'm reading : Frank Luna. mMainWndCaption is declared there, just as a simple std::wstring, and because this class is part of my project and has no inheritance from any DirectX class, i think i should be able to change any of it s member if i inherit from it. Thing is, i can't, and i still don't know why :-) – Handcart

But ShadowsApp & D3DApp are not static. How could i fall in that situation ?! – Handcart

@Yann: Then comment out this line, see what happens. Commenting out blocks of code might help you to locate the problem. Install breakpoint BEFORE this line, see what happens at this point. Debug by "stepping into". It might be possible that something within D3DApp accesses mMainWndCaption by pointer, and when you assign the string, data gets destroyed. "D3DApp is a class written completely from scratch" Which means it is more likely to have bugs than Microsoft class. – Extraordinary

ok cool, i'll try this, which is also what @Serra suggested. I'll come back here to post what i found. Thanks for your help ! – Handcart