Crash on exit

Started by
16 comments, last by alexisgreene 11 years, 2 months ago

I fixed the main loop but the problem still persists. I have spent many hours trying to locate the cause of this strange bug with no luck at all.

Advertisement

A few things you can try:

- use the newer DXGI components, e.g.: IDXGIFactory1 and IDXGIAdapter1 instead of IDXGIFactory and IDXGIAdapter

- don't manually create the DXGI objects, but retrieve/query them from a D3D device (using the default adapter):

D3DDevice->QueryInterface(__uuidof(IDXGIDevice1), (void **)&DXGIDevice);
DXGIDevice->GetParent(__uuidof(IDXGIAdapter1), (void **)&DXGIAdapter);
DXGIAdapter->GetParent(__uuidof(IDXGIFactory1), (void **)&DXGIFactory);

maybe m_pRenderTargetView and swap chain are the same before the shutdown.

maybe m_pRenderTargetView and swap chain are the same before the shutdown.

I stepped through the shut down code to test this theory and now the crash occurs when I call m_pDevice->Release(). The only code change I have made is the fix to the message loop that iedoc pointed out to me. No pointers had the same value during shut down as well.

I am going to rewrite my start up code in order to accommodate the changes suggested by eppo. I will post my results once I have time to test those changes out.

The application will crash if you try to release the device before releasing all the device's interface objects. Check that you release everything you initialized and set them all to null

After hours upon hours of attempting to debug this with no success, I discovered that the exact same breakpoint is triggered when I resize my window. I decided to focus less on Direct 3D (because I am 99% sure that my D3D code is close to correct) and more on only message that the debugger output is giving me:

HEAP[rdk_client_DEBUG.exe]: HEAP: Free Heap block 393ae90 modified at 393af48 after it was freed
rdk_client_DEBUG.exe has triggered a breakpoint.
This breakpoint, according to google, is triggered a little while after the actual illegal access has occurred. This explains why the crash seems to occur in different places after I make changes to the code. One recommendation I found for tracking down the true culprit is to "sprinkle" this assert throughout my code:
assert(_CrtCheckMemory());
The leading "_Crt" made me realize that I may be improperly using an STL container somewhere in my code. I will continue to search for the cause of this annoying bug and post the results. Thanks for the help so far.

i used neither stl nor some other third-party code, Actually i simplified my code as below:


#include <Windows.h>
#include <d3d11.h>
#pragma comment(lib,"d3d11.lib")
LRESULT CALLBACK Hur_WinProc11(HWND hWnd, unsigned int msg, unsigned int wParam, long  lParam)
{
	switch(msg)
	{
	case WM_DESTROY:
		{  
			PostQuitMessage( WM_QUIT );
			return 0;
		}
	}
	return DefWindowProc(hWnd, msg, wParam, lParam );
}


int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE , LPSTR , int) 
{
	IDXGISwapChain*          m_SwapChain;
	ID3D11Device*            m_D11Device;
	ID3D11DeviceContext*     m_DeviceContext;
	ID3D11RenderTargetView*  m_RenderTargetView;
	HRESULT result;
	WNDCLASSEX wcex;
	wcex.cbSize=					sizeof(WNDCLASSEX);
	wcex.style=						(CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS);
	wcex.cbClsExtra=				0;
	wcex.cbWndExtra=			0;
	wcex.hInstance=				GetModuleHandle( NULL );
	wcex.hIcon=						NULL;
	wcex.hCursor=					LoadCursor(NULL,IDC_ARROW);
	wcex.hbrBackground=   (HBRUSH)GetStockObject(WHITE_BRUSH);
	wcex.lpszMenuName=   NULL;
	wcex.hIconSm=				NULL;
	wcex.lpfnWndProc =		Hur_WinProc11;
	wcex.lpszClassName=    L"hhh";
	RegisterClassEx (&wcex);
	HWND hwnd = CreateWindow(wcex.lpszClassName, L"ggg", WS_OVERLAPPEDWINDOW, 40, 80, 60+16, 70+36, NULL, NULL, wcex.hInstance, NULL);



	D3D_FEATURE_LEVEL featureLevel = D3D_FEATURE_LEVEL_11_0;
	DXGI_SWAP_CHAIN_DESC swapChainDesc;
	ZeroMemory(&swapChainDesc, sizeof(swapChainDesc));

	swapChainDesc.BufferCount = 1;
	swapChainDesc.BufferDesc.Width  = 60+16;
	swapChainDesc.BufferDesc.Height = 70+36;
	swapChainDesc.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
	swapChainDesc.BufferDesc.RefreshRate.Numerator = 1;
	swapChainDesc.BufferDesc.RefreshRate.Denominator = 60;
	swapChainDesc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
	swapChainDesc.SwapEffect = DXGI_SWAP_EFFECT_DISCARD;
	swapChainDesc.OutputWindow = hwnd;
	swapChainDesc.SampleDesc.Count = 1;
	swapChainDesc.SampleDesc.Quality = 0;
	swapChainDesc.Windowed = true;

	result = D3D11CreateDeviceAndSwapChain(NULL, 
		D3D_DRIVER_TYPE_HARDWARE, 
		NULL, 
		0, 
		&featureLevel, 
		1, 
		D3D11_SDK_VERSION, 
		&swapChainDesc, 
		&m_SwapChain, 
		&m_D11Device, 
		NULL, 
		&m_DeviceContext);
	if(FAILED(result))
	{
		return 0;
	}

	ID3D11Texture2D* backBufferPtr;
	result = m_SwapChain->GetBuffer(0, __uuidof(ID3D11Texture2D), reinterpret_cast<void**>(&backBufferPtr));
	result = m_D11Device->CreateRenderTargetView(backBufferPtr, NULL, &m_RenderTargetView);
	backBufferPtr->Release();


 	m_DeviceContext->OMSetRenderTargets(1, &m_RenderTargetView, 0);
 	m_SwapChain->Present(0, 0); 


	if(m_SwapChain) m_SwapChain->Release();
	if(m_DeviceContext) m_DeviceContext->Release();
	if(m_RenderTargetView) m_RenderTargetView->Release(); 
	if(m_D11Device) m_D11Device->Release();


	return 1;
}                

The code seems correct, but this annoying bug still occured? What it really confused me is, no matter what the release() order is, the brake is always triggerd on the last release call.

Well, it turns out that STL wasn't the cause. Nor did that assert yield any different results. I am really beginning to believe that this is a bug with the VS2012 debugger because when I run the same debug executable from the folder (and not through the debugger) this breakpoint is never triggered. Not when I resize and not when I exit the application.

This topic is closed to new replies.

Advertisement