|
This is the view from the disassembly window when running the app in VS2005 on my XP machine:
{
AfxMessageBox(_T("LoadFrame failed"));
00423F04 push 0
00423F06 push 0
00423F08 push 42A950h
00423F0D call AfxMessageBox (410E02h)
delete pMainFrame;
00423F12 mov ecx,dword ptr [ebp-10h]
00423F15 mov dword ptr [ebp-78h],ecx
00423F18 mov edx,dword ptr [ebp-78h]
00423F1B mov dword ptr [ebp-74h],edx
00423F1E cmp dword ptr [ebp-74h],0
00423F22 je CMyApp::InitInstance+2CBh (423F3Bh)
00423F24 push 1
00423F26 mov eax,dword ptr [ebp-74h]
00423F29 mov edx,dword ptr [eax]
00423F2B mov ecx,dword ptr [ebp-74h]
00423F2E mov eax,dword ptr [edx+4]
00423F31 call eax
00423F33 mov dword ptr [ebp-0A0h],eax
00423F39 jmp CMyApp::InitInstance+2D5h (423F45h)
00423F3B mov dword ptr [ebp-0A0h],0
return FALSE;
00423F45 mov dword ptr [ebp-7Ch],0
00423F4C mov dword ptr [ebp-4],0FFFFFFFFh
00423F53 lea ecx,[ebp-44h]
00423F56 call CCommandLineInfo::~CCommandLineInfo (410DD8h)
00423F5B mov eax,dword ptr [ebp-7Ch]
00423F5E jmp 0042409A
}
m_pMainWnd = pMainFrame;
00423F63 mov ecx,dword ptr [ebp-94h]
00423F69 mov edx,dword ptr [ebp-10h]
00423F6C mov dword ptr [ecx+20h],edx And this is the DrWatson log from the same exe file but run on W2K
State Dump for Thread Id 0x3b8
eax=00778f00 ebx=ffffffff ecx=00778f00 edx=00000000 esi=00433a68 edi=00433a68
eip=00423f8e esp=0012fe70 ebp=0012ff1c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206
function: <nosymbols>
00423f72 8b4df0 mov ecx,[ebp+0xf0] ss:00ba9e02=????????
00423f75 894d88 mov [ebp+0x88],ecx ss:00ba9e02=????????
00423f78 8b5588 mov edx,[ebp+0x88] ss:00ba9e02=????????
00423f7b 89558c mov [ebp+0x8c],edx ss:00ba9e02=????????
00423f7e 837d8c00 cmp dword ptr [ebp+0x8c],0x0 ss:00ba9e02=????????
00423f82 7417 jz 0042a99b
00423f84 6a01 push 0x1
00423f86 8b458c mov eax,[ebp+0x8c] ss:00ba9e02=????????
00423f89 8b10 mov edx,[eax] ds:00778f00=00000000
00423f8b 8b4d8c mov ecx,[ebp+0x8c] ss:00ba9e02=????????
FAULT ->00423f8e 8b4204 mov eax,[edx+0x4] ds:00a79ee6=????????
00423f91 ffd0 call eax
00423f93 898560ffffff mov [ebp+0xffffff60],eax ss:0012fe7c=00000040
00423f99 eb0a jmp 004306a5
00423f9b c78560ffffff00000000 ss:0012fe7c=00000040
mov dword ptr [ebp+0xffffff60],0x0
00423fa5 6a00 push 0x0
00423fa7 6a00 push 0x0
00423fa9 686caa4200 push 0x42aa6c
00423fae e84fcefeff call 00410e02
00423fb3 c7458400000000 mov dword ptr [ebp+0x84],0x0 ss:00ba9e02=????????
00423fba c745fcffffffff ss:00ba9e02=????????
mov dword ptr [ebp+0xfc],0xffffffff
00423fc1 8d4dbc lea ecx,[ebp+0xbc] ss:00ba9e02=????????
*----> Stack Back Trace <----*Now I do not know why the addresses are different (off by 0x60 bytes)
Why the instruction just before the push 1 is different - VS debugger has it as jz, DrWatson has it as je
Why the pointers are different? mov ecx,dword ptr [ebp-10h] as opposed to mov ecx,[ebp+0xf0]
Is the copy of DrWatson on the W2K machine all screwed up?
If I look for the instruction addresses reported by DrWatson in VS I can not find them.
I assumed that the app was crashing in delete because it crashed immediately after I got the message box and DrWatson reported the fault to be in the code that matches up (almost) with the code the VS shows for the delete function.
Why would the app run flawlessly on XP but crash so badly on W2K? I think what I really need is some clear instructions on how to setup VS2005 to do remote debugging. Anything I have tried from reading MSDN on the subject has failed with VS giving me cryptic error messages.
|
|
|
|
|
JE and JZ are synonymous - both jump if the zero flag is set. cmp eax, 15 checks if eax==15. But what it really does is subtract 15 from eax and set the flags appropriately. Thus if they are equal, the zero-flag will be set.
As for the different pointers - the instructions in question have a sign-extended MOD/RM operand. Dr.Watson is for some reason treating the offset as an unsigned char rather than the signed char it really is.
I still don't know why the load addresses are different. You're not doing anything funky with EXE alignment, are you?
It looks to me like memory corruption. It is failing while trying to load the address of the virtual destructor of the pMainFrame object. Somehow the vtbl pointer has been zeroed out. Are you by any chance doing a memset to clear a bunch of class variables? I've seen that many times.
But as to why this fails on only W2K, I have no idea at the moment. What kind of stuff does the app use? (i.e. any os components that could be different on 2k/xp?)
That doesn't really help much, now, does it  But it's about all I can think of now.
Mike
|
|
|
|
|
Mike_V wrote: What kind of stuff does the app use? (i.e. any os components that could be different on 2k/xp?)
BINGO !!!!
I was using the CS_DROPSHADOW style on a floating tool window. Removed that style and everything worked.
Thanks much for the hint. You get my 5 for that
|
|
|
|
|
Cool! 
I guess I've been reading Raymond Chen's blog enough that some of his "psychic powers" have rubbed off on me! 
But seriously - glad to be of help. Though I still don't get why that caused the problem we were seeing. But at this point it's probably better not to ask.
Mike
|
|
|
|
|
Mike_V wrote: Though I still don't get why that caused the problem we were seeing. But at this point it's probably better not to ask.
This code was called from CMainFrame::OnCreate()
BOOL CToolWnd::Create(CWnd *pParent)
{
return CreateEx(WS_EX_TOOLWINDOW | WS_EX_TOPMOST,
AfxRegisterClass(CS_DROPSHADOW | CS_SAVEBITS,
NULL, NULL, NULL),
...);
}I would have thought that the the create function would simply fail to create a window, not crash the entire app. It certainly would have been easier to debug . I have now added code to check the OS and remove the CS_DROPSHADOW style if running on W2K.
Maybe a guy should not ask why, but I would really like to know if anybody has any idea
|
|
|
|
|
Looks like CS_DROPSHADOW, flag isnt defined in W2k, SystemParametersInfo[^]
MSDN wrote: SPI_SETDROPSHADOW Enables or disables the drop shadow effect. Set pvParam to TRUE to enable the drop shadow effect or FALSE to disable it. You must also have CS_DROPSHADOW in the window class style.
Windows 2000: This value is not supported until Windows XP.
PJ Arends wrote: not crash the entire app. It certainly would have been easier to debug
It's more fun when seemingly simple stuff crashes everything.  Would you have looked at a memory dump other wise?
I of coarse just like you would have expected it to just fail at the undefined feature.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
Peter Weyzen wrote: What's the value of IDR_MAINFRAME?
128, the standard MFC value.
Sorry I forgot to add that earlier.
|
|
|
|
|
I have a series of pages in a wizard; when I press the "next" button to go to the next page, I can validate the current page values in the OnWizardNext and return -1 to stay on the same page if there are some bad values on the page.
but, when I'm at the last page, there's the "Finish" button, and will generate an OnWizardFinish but if there are invalide values on the last page, there is no way (*) of preventing the wizard to finish ( stay on the current page )
(*) I'm certain that there is a way to do it, that's why I'm asking, I think I could disable the "Finish" button and enable it if all my values are valid.
Thanks.
Max.
|
|
|
|
|
What happens if you return FALSE from OnWizardFinish()? The docs say it prevents the property sheet from being destroyed, but is that the same as leaving the page open and usable?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I am using VS.NET 2003. I have placed a DateTimePicker and am using time. When I click on the HH field, I can not click (using mouse)on the SS field. I have to exit the dialog then come back in. I realize I can use the keyboard left and right arrows but can I use the mouse to click on the fields after the first is selection.
|
|
|
|
|
how to get column count of CListCtrl?
or by any win32 function?
thx
|
|
|
|
|
See
<br />
CHeaderCtrl* m_Header=(CHeaderCtrl*)m_List1.GetDlgItem(0); <br />
int nCount = m_Header->GetItemCount(); <br />
|
|
|
|
|
WhiteSky wrote: CHeaderCtrl* m_Header=(CHeaderCtrl*)m_List1.GetDlgItem(0);
int nCount = m_Header->GetItemCount();
Or a slightly more readable way:
CHeaderCtrl* pHeader = m_List.GetHeaderCtrl();
int Count = pHeader->GetItemCount();
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
yes,
|
|
|
|
|
Sir,
I want to make the setup of my application in vc++6.0.please help.
Thanks
|
|
|
|
|
|
The Professional version of VC6 came with an optional package for creating InstallShield installation exe's. It will integrate with the IDE and is fairly simple to use for most applications.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
When running my programs in debug mode (not in the debugger) is it possible to ouput strings to the debug window still? Or any other similar function? OutputDebugString() only seems to work when stepping through the code.
|
|
|
|
|
You have to use F5, not Ctrl+F5, to see output from OutputDebugString().
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I already know that, as stated in my origional question. I am looking for a similar feature which will do the same job without stepping through the code (Ctrl+F5).
I'm thinking a quick way to do this would be to create a new console window and send the strings to that as opposed to the debugger.
|
|
|
|
|
waldermort wrote: I already know that, as stated in my origional question. I am looking for a similar feature which will do the same job without stepping through the code (Ctrl+F5).
Stepping through the code is not required. 
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
yeah, but only if there are no breakpoints in the path of execution.
I thought that maybe VS++ would have added the feature I am looking for, since I'm building with their tool it's only logical to assume I will also be debugging with it. Sometimes, especially with many loops, it's kinda hard to spot where an error occurs, but if the output is going to the window, like I want, atleast i could narrow it down a little.
|
|
|
|
|
|
I have a picture control on a dialog application.
My goal is to be able to paint the control area say White. Then write some text in black.
I retrieved a pointer dc to the picture control.
Then i did a GetClientRect to get the dimensions.
Now i do a FillSolidRect(pRect, RGB(255, 255, 255))
I figured that this should paint the picture control
This did not.
Then i tried to write the text by Creating a Pen in the color black
Then Using Drawtext from the dc to write out some text on the picture control
This did not work either.
This should be pretty easy so i must be using the wrong api's
Any ideas???
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
