<< Thus if x is negative number, the compiler will complain
about assertion errors at that line (it makes the program
EASIER and FASTER to debug) >>
thats not quite true, assertion macro is called during runtime, not during compile or link time. When not in debug mode the prepocessor defines a NDEBUG (or eqiuvalent depending or the system) identifier and the macro is redefined to do nothing (void)0. That's why sebfrost's errors went away when switching to release mode. I would go back to debug and try to identify the problem. I immediatly see that you are passing NULL,0,0,int,int,NULL to the SetWindowPos(HWND hWndInsertAfter,int x,int y,int cx,int cy,UINT nFlags), so you are passing NULL as the handle to the hWndInsertAfter parameter (this causes the assert(...) to abort, because NULL is not a valid window handle)...to fix the problem, pass a valid value to the handle, which can can be (HWND_BOTTOM, HWND_NOTOPMOST, HWND_TOP, HWND_TOPMOST), so the call looking like this m_bmp.SetWindowPos(HWND_TOP,0,0,cx,cy,NULL); would reposition the window and place it at the top of the stacking order ( actually this is also not 100% correct, because we are still passing NULL in place of the nFlags) ... so, if you could care less about stacking order you can pass SWP_NOZORDER in place of the uFlags parameter. The call would look like this m_bmp.SetWindowPos(HWND_TOP,0,0,cx,cy,SWP_NOZORDER);. (The position flags are defined in Winuser.h definition file). That should hepefully do it. LMK if it doesn't, i've been away from Win32/MFC programming for a while so i might not be 100% on target with my explanation.