I'm migrating a legacy GUI application to VS2012. When running this application in debug mode, I'm getting a debug assertion when I try to instantiate a toolbar with the following line of code:
if(!m_wndMain.Create(this) || !m_wndMain.LoadToolBar(IDR_MAIN))
After digging around in MFC code, I found that the following line has changed in bartool.cpp has changed in MSVC10->11 from:
if (lpBitmap == NULL)
to:
if ((lpBitmap == NULL) || (lpBitmap->biBitCount > 8))
in AfxLoadSysColorBitmap.
In my case lpBitmap->biBitCount = 24 which causes AfxLoadSysColorBitmap to return NULL which in turn causes the debug assertion.
Any ideas on how to rectify my program's behavior to avoid this debug assertion?
Apart from changing the bitmap to be 8-bit (256 colors) your best option is to use CMFCToolBar instead. This supports higher bit-depth bitmaps (including 24 and 32 bit) bitmaps.
elad please check that the bitmap images you are using are indeed only 8 bit.
i think you are using 24 bit images. hence the error.
try to convert them into 8 bit , bitmaps
Related
I have this project that I'm working on for a while now, and it was working just fine before I switched from releasing an x86 version to an x64 one.
This is the line of code where the error appeared:
ReadProcessMemory(a.hProcess, LPCVOID(b->Ebx + 8), LPVOID(&c), 4, 0);
I don't understand assembly but when the Error appeared at b->Ebx I changed it to b->Rbx. and it compiled and run but it didn't do the job it was supposed to do.
Am I using the wrong register?
After a little bit of debugging
pe_dos_h = PIMAGE_DOS_HEADER(pe_image);
pe_nt_h = PIMAGE_NT_HEADERS(DWORD(pe_image) + pe_dos_h->e_lfanew);
//error when trying to assign a value or access the signature in nt-headers
//ERROR: read access violation
IMAGE_NT_HEADERS* pe_nt_h->Signature == IMAGE_NT_SIGNATURE;//0x00004550-PE00
The pe_image is raw data copied from a PE(.exe) file. Is the difference is in handling x86 PE image vs x64 one?
This is a simplified version of the code. If you think the problem is out of the scope of this piece of code let me know.
The problem was in the way I was defining the IMAGE_SECTION_HEADER, In x64 architecture, I had to use the x64-specific datatype IMAGE_SECTION_HEADER64.
and also when casting pe_nt_h = PIMAGE_NT_HEADERS(DWORD_PTR(pe_image) + pe_dos_h->e_lfanew);
I had to use DWORD_PTR instead of just DWORD because it was missing some bits.
here is the solution code for the simplified version I provided in the post:
PIMAGE_DOS_HEADER pe_dos_h = PIMAGE_DOS_HEADER(pe_image);
PIMAGE_NT_HEADERS64 pe_nt_h = PIMAGE_NT_HEADERS(DWORD_PTR(pe_image) + pe_dos_h->e_lfanew);
I am trying to use the Eigen code (http://eigen.tuxfamily.org/index.php?title=Main_Page) in Visual Studio 2013 on Windows 8-64 bit platform, but I am getting the error related to "Assertion Failed" in MapBase.h file.
...........
eigen_assert(EIGEN_IMPLIES(internal::traits<Derived>::Flags&AlignedBit,(size_t(m_data) % 16) == 0) && "data is not aligned");
..............
Please let me know how can I resolve this issue.
As the assert tells you, the data m_data isn't aligned to a correct 32/64bit boundary. The project is configured to check the alignment of pointers.
Check the call stack, probably you used a wrong pointer (i.e. -1) for such an object, or you have a heap corruption, or you overwrote memory.
I've used the following code to draw on a Image using a wxMemoryDC.
To do so I used a wxPen and changed the settings of the pen as in the following code. The code compiles and runs perfectly in windows environment. But in Ubuntu it draws the lines but the pen size stays correctly for a very little time and then the pen size becomes very low.(As shown in the image) It is not an error of the m_pensize variable because it always prints the correct value. Why does this works so strange in ubuntu when it works correctly in windows?.
(m_graphics is the memoryDC here)
if (x<m_backgroundImage.GetWidth() && y< m_backgroundImage.GetHeight()){
m_graphics.SelectObject(m_maskImage);
wxPen* pen;
if (m_isDrawing){
pen = wxThePenList->FindOrCreatePen(*wxRED, m_penSize);
printf("Pen size is %d", m_penSize);
}
else{
pen = wxThePenList->FindOrCreatePen(*wxBLACK, m_penSize);
}
if (m_pentype != Circle){
pen->SetCap(wxCAP_PROJECTING);
}
m_graphics.SetPen(*pen);
m_graphics.DrawLine(m_lastX,m_lastY,x,y);
m_graphics.SelectObject(wxNullBitmap);
}
In windows it is shown Correctly
In linux The pen size is changed unexpectadly.
Your help is greatly appreciated.
If the same code behaves differently in wxMSW and wxGTK, then it's probably a bug in wxWidgets itself, however to fix it it needs to be reproduced in some simple to test way, ideally by making the smallest possible change to the wxWidgets drawing sample and opening a ticket attaching this change as a patch to it.
To simplify the code as much as possible, I'd recommend:
Getting rid of wxThePenList and just creating the pen directly. It's unlikely that the bug is here, but who knows.
Check if it's not due to SetCap() call, this is the most likely candidate IMHO.
I have just tested my DirectX game on a Windows 2000 SP4 system but it won't receive any mouse clicks!
This is how I check for mouse clicks :
unsigned int mButtons = 0;
if (GetKeyState(VK_LBUTTON) < 0) mButtons |= HIDBoss::MOUSE_LEFT;
if (GetKeyState(VK_RBUTTON) < 0) mButtons |= HIDBoss::MOUSE_RIGHT;
if (GetKeyState(VK_MBUTTON) < 0) mButtons |= HIDBoss::MOUSE_MIDDLE;
if (GetKeyState(VK_XBUTTON1) < 0) mButtons |= HIDBoss::MOUSE_4;
if (GetKeyState(VK_XBUTTON2) < 0) mButtons |= HIDBoss::MOUSE_5;
etc...
This code works perfectly on Windows 7 and XP 32/64bit.
The problem is fixed if I use the OIS library instead - which uses DirectX input - but it contains a few bugs so I would rather avoid it.
Can anyone suggest why GetKeyState won't work on W2K? Could it be because the system hasn't been updated - through Windows Update - for the last couple of years..?
Thank you for your time,
Bill
I'm not sure why it doesn't work but I'd recommend using GetAsyncKeyState instead.
Edit: In answer to your comment. It is merely a suggestion but its, equally, pretty easy to find out if the buttons are swapped by calling:
GetSystemMetrics(SM_SWAPBUTTON)
Your big problem arises from the fact that GetKeyState is not supposed to return a value for mouse buttons only keyboard buttons. the fact it DOES work in some OSs is not something you are supposed to be able to rely on across all OSs.
An application calls GetKeyState in
response to a keyboard-input message.
This function retrieves the state of
the key when the input message was
generated.
Its worth noting that it makes specific mention of calling it in response to a keyboard-input message (ie WM_KEY[UP/DOWN]). Equally there is no mention that this should work for mice. As such you really are better off just using GetAsyncKeyState...
I am currently trying to get to the bottom of a client crash with one of our applications. I have wrapped the app in an exception handler which creates a mini-dump when the crash occurs.
The application crashes with the exception c0000139 (of which there isn't a huge amount of documentation).
The callstack looks like this
ntdll.dll!_RtlRaiseStatus#4() + 0x26 bytes
ntdll.dll!_LdrpSnapThunk#32() + 0x26f48 bytes
ntdll.dll!_LdrpSnapIAT#16() + 0xd9 bytes
ntdll.dll!_LdrpHandleOneOldFormatImportDescriptor#16() + 0x7a bytes
ntdll.dll!_LdrpHandleOldFormatImportDescriptors#16() + 0x2e bytes
ntdll.dll!_LdrpWalkImportDescriptor#8() + 0x11d bytes
ntdll.dll!_LdrpLoadDll#24() - 0x265 bytes
ntdll.dll!_LdrLoadDll#16() + 0x110 bytes
kernel32.dll!_LoadLibraryExW#12() + 0xc8 bytes
odbc32.dll!_ODBCLoadLibraryEx#12() + 0x29 bytes
odbc32.dll!_LoadDriver#12() + 0x119f bytes
odbc32.dll!_SQLDriverConnectW#32() + 0x1be bytes
odbc32.dll!_SQLDriverConnect#32() + 0x125 bytes
It looks like the program is trying to create a database connection (to Oracle via ODBC) and somehow failing to either find the dll or has found a dll with the wrong entry point.
I was wondering if anyone could offer advice an how to track this problem down further, or if anyone has experienced this problem I'd be interested in hearing how you solved it.
Thanks in advance
Rich
That exception code is Entry point not found - something is trying to load a DLL and the DLL cannot find all the DLLs it needs.
Use depends.exe to show what the DLL requires.
Enable loader snaps (gflags -i yourapp.exe +sls) and have it pinpoint the library its failing to find/load (starting the program under the debugger will spew all the loader diagnostics).
Alternatively, get the name of the library from the crash dump by examining parameters of LoadLibraryExW call.
Thanks for all the responses.
Turns out (at least this seems like it was the problem) that we had a configuration problem. Half of the software was set to load the 9i drivers and half of the software was expecting the 10g drivers.
It's early days yet and we need to test this, however it seems very likely that this was the cause.
Cheers
Rich