C / C++ / MFC

5-Oct-08 21:36

Hello everyone,

Not sure whether any of you met with the same issue. I am using x64 WinDbg, it is fine when debugging on x64 machine for an x64 binary -- the source code window is displayed automatically when a break point is hit.

But with x64 WinDbg, when debugging on a x64 machine for an x86 binary, the source code window is not displayed even when a break point is hit.

My questions are,

1. Is it expected behavior?
2. How to make the source window displayed when debugging x86 binary?

thanks in advance,
George

_AnsHUMAN_ 5-Oct-08 21:59

_AnsHUMAN_

5-Oct-08 21:59

do you verify, that you have the proper symbols, the source and image file path set properly in windbg? Also the version of the binaries and the source code are the same...

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

George_George5-Oct-08 23:02

5-Oct-08 23:02

I think so, could you reproduce the problem I described?

regards,
George

_AnsHUMAN_ 5-Oct-08 23:13

_AnsHUMAN_

5-Oct-08 23:13

The source code window refuses to open if you don't have proper symbols set or don't have the correct version of binaries and the source. So this would more likely be the case at your end...

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

George_George5-Oct-08 23:29

5-Oct-08 23:29

Thanks AnShUmAn,

Here is my source code and related Windbg output after further experiment. My questions/comments,

1. I find if I execute command .effmach x86 at the beginning, also with correct symbol path and source path, source code window is showing when break point is hit in source code;
2. My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?
3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?

More details, I donot know why breaks here,

--------------------
(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000`7d61002d cc              int     3
0:000:x86> k
ChildEBP          RetAddr           
002dfb48 7d649b01 ntdll32!DbgBreakPoint
002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c
002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0
00000000 00000000 ntdll32!KiUserApcDispatcher+0x25
--------------------

Here is the whole output.

--------------------
ntdll!DbgBreakPoint:
00000000`77ef2aa0 cc              int     3
0:000> .effmach x86
Effective machine: x86 compatible (x86)
0:000:x86> bp main
0:000:x86> bl
 0 e x86 00000000`00411430     0001 (0001)  0:**** TestDebug1!main
0:000:x86> g
ModLoad: 00000000`77d40000 00000000`77eb3000   NOT_AN_IMAGE
ModLoad: 00000000`7d4c0000 00000000`7d5f0000   NOT_AN_IMAGE
ModLoad: 00000000`7d600000 00000000`7d6f0000   C:\WINDOWS\SysWOW64\ntdll32.dll
ModLoad: 00000000`77d40000 00000000`77eb3000   NOT_AN_IMAGE
ModLoad: 00000000`77c20000 00000000`77d2c000   NOT_AN_IMAGE
ModLoad: 00000000`7d4c0000 00000000`7d5f0000   C:\WINDOWS\syswow64\kernel32.dll
ModLoad: 00000000`10200000 00000000`10323000   C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_F863C71F\MSVCR90D.dll
(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000`7d61002d cc              int     3
0:000:x86> k
ChildEBP          RetAddr           
002dfb48 7d649b01 ntdll32!DbgBreakPoint
002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c
002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0
00000000 00000000 ntdll32!KiUserApcDispatcher+0x25
0:000:x86> g
Breakpoint 0 hit
TestDebug1!main:
00000000`00411430 55              push    ebp
0:000:x86> k
ChildEBP          RetAddr           
002dff68 00411a38 TestDebug1!main [d:\visual studio 2008\projects\testdebug1\testdebug1\main.cpp @ 20]
002dffb8 0041187f TestDebug1!__tmainCRTStartup+0x1a8
002dffc0 7d4e7d2a TestDebug1!mainCRTStartup+0xf
002dfff0 00000000 kernel32!BaseProcessStart+0x28

#include <iostream>
using namespace std;
int foo()
{
 int b = 300;
 return b;
}
int goo()
{
 int a = 400;
 return a;
}
int main()
{
 int a = 200;
 int* b = &a;
 foo();
 a = 400;
 goo();
 return 0;
}
--------------------

regards,
George

_AnsHUMAN_ 5-Oct-08 23:59

_AnsHUMAN_

5-Oct-08 23:59

George_George wrote:
window is showing when break point is hit in source code;
2. My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?

.effmach x86 -Use x86, amd64, ia64, or ebc processor mode
This setting influences many debugger features:
-> which processor's unwinder is used for stack tracing
-> which processor's register set is active
So, if you have multiple processors you can use this command early when you start debugging.

George_George wrote:
3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?

I will try to reproduce this once I get some time off. Smile | :)

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

George_George6-Oct-08 0:22

Loading DLLs more than once

6-Oct-08 0:22

Thanks AnShUmAn,

_AnShUmAn_ wrote:
I will try to reproduce this once I get some time off.

Looking forward to your reply. I do not know why for the same breakpoint setting for x64 binary, we only break once, and for x86 binary, we break twice.

regards,
George

DSPCottage5-Oct-08 21:27

DSPCottage

5-Oct-08 21:27

Dear All
in a project I need to load a DLL more than once. (15 times at least)
This DLL is used to compress raw voice into mp3 format.

Is it possible to do this.
If there is any points which I should consider please let me know.
Regards
Monhi

Re: Loading DLLs more than once

CPallini5-Oct-08 22:14

Re: Loading DLLs more than once

5-Oct-08 22:14

Gut Mikh Tappe wrote:
in a project I need to load a DLL more than once. (15 times at least)

Why?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

DSPCottage5-Oct-08 22:40

DSPCottage

5-Oct-08 22:40

The DLL which I want to use is a mp3 compressor which only compresser the sound of a channel.
But I need to do the same job for 15 channels at least.
Thus it was neccessary to load it more than 15 times.

Re: Loading DLLs more than once

CPallini5-Oct-08 22:49

5-Oct-08 22:49

Well, if I need to use the same function in different threads, I don't load the corrensponding DLL many times... Roll eyes | :rolleyes:

SHFileOperation

MsmVc5-Oct-08 21:02

MsmVc

5-Oct-08 21:02

Hi All

I am useing SHFileOperation for copy folder.It's working nice for folder.Can i use SHFileOperation for file also.I mean when i copy folder like this.

C:\\Test(Source Folder)
C:\\Test2(Deswtination folder)

This is working fine.
But when i copy file like this then it's not working.

C:\\log.txt(Source)
C:\\   (Destination)

Plz help me Rose | [Rose]

CPallini5-Oct-08 22:16

5-Oct-08 22:16

MsmVc wrote:
C:\\log.txt(Source)C:\\ (Destination)

And whats should it do (i.e. what is the expected 'working' behaviour)?
Smile | :)

Re: SHFileOperation [modified]

fantasy12155-Oct-08 22:20

fantasy1215

5-Oct-08 22:20

void CTestgarbageDlg::OnButton1() 
{
	SHFILEOPSTRUCT	shop;
	shop.hwnd = this->GetSafeHwnd();
	shop.wFunc = FO_COPY;
	shop.pFrom = _T("c:\\AUTOEXEC.BAT\0");
	shop.pTo = _T("d:\0");
	shop.fFlags = FOF_FILESONLY;
	
	int iRet = -1;
	iRet = SHFileOperation(&shop);
	if (iRet == 0)
	{
		//sucess
		AfxMessageBox(_T("sucess"));
	}
	else
	{
		AfxMessageBox(_T("fail"));
	}
	
}

I've tried the code above, it works fine. Hope it helps you.

CPallini5-Oct-08 22:28

5-Oct-08 22:28

fantasy1215 wrote:
shop.pFrom = _T("c:\\AUTOEXEC.BAT\0");
shop.pTo = _T("d:\0");

~~Why do you double terminate the strings?~~

Nevermind, it was my ignorance.
Smile | :)

modified on Monday, October 6, 2008 4:38 AM

SandipG 5-Oct-08 22:34

SandipG

5-Oct-08 22:34

Documentation says to end it with two null chars.
Rajesh has verified it it works with single null termination also.

Regards,
Sandip.

Rajesh R Subramanian5-Oct-08 22:43

Rajesh R Subramanian

5-Oct-08 22:43

SandipG wrote:
Rajesh has verified it it works with single null termination also.

Actually, I just said that it worked in *that particular* case, as it might work with certain cases, which cannot be predicted.

But that isn't the best thing to do. Because if there is a buffer overrun, then that could be disastrous. And - Those strings must be double null-terminated. Smile | :)

Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche

.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]

CPallini5-Oct-08 22:50

5-Oct-08 22:50

You're definitely a nit-picker!
Big Grin | :-D