C / C++ / MFC

Rajesh R Subramanian29-Jun-08 23:41

29-Jun-08 23:41

I am not sure I get your question right, but you are probably looking for OutputDebugString()[^].

Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP

George_George30-Jun-08 1:10

30-Jun-08 1:10

Sorry Rajesh!

My bad English. I am asking if we are executing inside a function, how to print the values for input parameters for this function -- under WinDbg tool?

regards,
George

Rajesh R Subramanian30-Jun-08 1:24

30-Jun-08 1:24

I still am not getting your question correctly. I am presuming that you want to print the value of certain variables on a debug window during program execution. If I am right, then the API I linked you to will do the job.

TCHAR *szVal = _T("Hello world");
TCHAR szDbg[100];
int nVal = 100;

sprintf(szDbg, _T("szVal is [%s] nVal is [%d]"), szVal, nVal);
OutputDebugString(szDbg);

szVal = _T("Modified string");
nVal = 299;

sprintf(szDbg, _T("szVal is [%s] nVal is [%d]"), szVal, nVal);
OutputDebugString(szDbg);

The output must be visible in WinDbg window.

Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP

George_George30-Jun-08 1:46

30-Jun-08 1:46

Thanks Rajesh,

I understand your code and what you are trying to solve. But I have not made myself understood again.

I think an example clarifies everything.

1. Suppose we are executing in function CoInitializeEx or any function which is not written by you but provided by system SDK, in which you do not know the code, only the function prototype;
2. You set a breakpoint to such system function, say CoInitializeEx, say using WinDbg tool;
3. The program debugs at CoInitializeEx, the you step into the function;
4. It is not your code which calls CoInitializeEx, but some other system functions with long call stack;
5. Now, since you are executing in function CoInitializeEx, you want to print out the input parameter value of function CoInitializeEx, how could you perform this job in WinDbg?

(you can not add code like you showed above, since you can modify code of CoInitializeEx or any sytem API function which calls CoInitializEx)

regards,
George

Rajesh R Subramanian30-Jun-08 2:15

30-Jun-08 2:15

I see your concern now. I don't know an awful lot of this, but I think that you'll need to have your own mechanism which will intercept the calls at kernel level. I *might* be totally wrong, but this[^] could get you started.

George_George wrote:
(you can not add code like you showed above, since you can modify code of CoInitializeEx or any sytem API function which calls CoInitializEx)

You probably wanted to say "cannot". Smile | :)

Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP

George_George30-Jun-08 2:27

30-Jun-08 2:27

Thanks Rajesh,

The article describes a comprehensive solution. But I think there should be a simple solution in debugging tool.

Here are my points,

1. We can enter into any assemly language code, and see the assembly language code and watch for register and memory values;
2. If I remember correctly, if the parameter of function is small enough, the input parameters' values are stored in some specific registers, and we can print them out?
3. I roughly remember the input parameter is put around frame base pointer and we could dump the memory address aronud the frame base pointer?

I think there should be some handful commands to do such work manually -- and my purpose is just to work on it manually. Smile | :)

But after some search, I can not find exact answers.

Any comments or replies to my further description? :-P

BTW: yes, I should say can not.

regards,
George

Rajesh R Subramanian30-Jun-08 2:48

30-Jun-08 2:48

George_George wrote:
The article describes a comprehensive solution. But I think there should be a simple solution in debugging tool.

If we do it on our own, I think that it is not going to be simple. But neither am I able to think of a debugging tool or mechanism which will let you do this on a "ready-made" basis.

George_George wrote:
2. If I remember correctly, if the parameter of function is small enough, the input parameters' values are stored in some specific registers, and we can print them out?

Even if the function parameter is small enough, the location where the parameters would be stored will be dependent on the calling convention used. If it is __stdcall (WINAPI), then the function parameters would be simply pushed onto the stack (not on the registers). There is a chance that the parameters (and yes, if being small enough) will be placed on registers if the calling convention is __fastcall. But there's no guarentee, as it might depend upon availability of registers at the time of call as well.

Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP

George_George30-Jun-08 16:03

30-Jun-08 16:03

Hi Rajesh,

Basically I agree with you. Have you tried the dv command in WinDbg? Looks it works pretty good. Smile | :)

regards,
George

Hamid_RT30-Jun-08 23:08

Hamid_RT

30-Jun-08 23:08

Do you want to print prototype of functions that you are using?

George_George30-Jun-08 23:24

30-Jun-08 23:24

No, Hamid!

I want to print out input parameters' value. Any ideas?

regards,
George

Hamid_RT1-Jul-08 21:39

Hamid_RT

1-Jul-08 21:39

Hi again,
Today I was searching for a object and on this search I found this site of course I dont see this site perfect but it has a forum for Debuggers like WinDbg and etc I guess maybe this site is helpful for you.http://www.openrce.org/forums/[^]

George_George2-Jul-08 1:42

2-Jul-08 1:42

Thanks Hamid!

I think this forum is for OllyDbg tool, not for WinDbg tool. Any comments?

regards,
George

Hamid_RT2-Jul-08 18:16

Hamid_RT

2-Jul-08 18:16

But I think I saw WinDbg on that site.

George_George6-Jul-08 3:12

6-Jul-08 3:12

Thanks Hamid,

I think there are very few posts dedicated about WinDbg, not dedicated sub-forum which deals with WinDbg. Could you check again please? Please feel free to correct me if I am wrong. Smile | :)

regards,
George

Check file in use

Karismatic29-Jun-08 23:28

Karismatic

29-Jun-08 23:28

Hi All,

I am not able to find out the solution of how to find out whether a file is ready to use or not. I have tried several ways to do this but unable to do the same, please refer me to some solution.

Regards,
Pankaj Sachdeva

There is no future lies in any job but future lies in the person who holds the job

SandipG 29-Jun-08 23:31

SandipG

29-Jun-08 23:31

Karismatic wrote:
whether a file is ready to use or not.

What does you mean by this??

Regards,
Sandip.

Saurabh.Garg29-Jun-08 23:37

29-Jun-08 23:37

What do you mean by file is ready?

Saurabh

Karismatic29-Jun-08 23:42

Karismatic

29-Jun-08 23:42

I mean one process in writting a file which i want to access but before I open it i want to test whether it is written completely or not. I am using this code but it is not working properly

// attempt to open existing file.
  FileHandle = CreateFile (FileName, 
                           GENERIC_READ,
                           0, 
                           NULL,
                           OPEN_EXISTING, 
                           FILE_ATTRIBUTE_NORMAL,
                           NULL);
  // if unable to open the file 
  // then return failure.
  if (FileHandle == INVALID_HANDLE_VALUE)
  {
    // return failure.
    return (FALSE);
  } // if FileHandle
  // close the open file handle.
  CloseHandle (FileHandle);
  return TRUE

Regards,
Pankaj Sachdeva

There is no future lies in any job but future lies in the person who holds the job

Function pointer corrupts the stack or heap

SandipG 30-Jun-08 0:14

SandipG

30-Jun-08 0:14

Why don't you use some synchronization technique between the two processes??

Regards,
Sandip.

BadKarma29-Jun-08 22:55

BadKarma

29-Jun-08 22:55

Hi,

I have encountered this really strange bug. For a new project I have split a old, working class and its member class into two single classes (functional, wrapper).
When I use the same code that has worked for years, it crashes with heap or stack corruption. I have narrowed the bug to the use of a function pointer in the wrapper class to a member of the functional class. When i add this pointer as a member of the wrapper class, the corruption happenes i don't even have to call it.
This is the code that does the woe.

int _tmain(int argc, _TCHAR* argv[])
{
  functional oFun;

  {
    // this is to use the scope effect
    wrapper wrap(&oFun);  
  }
  
  return 0;
}

When exiting the stack is corrupted.
The is the code of the wrapper class
--wrapper.h--

#pragma once
class functional;
class wrapper
{
public:
  wrapper(functional* pFun);
  ~wrapper(void);
  
  void (functional::*pExitFunction)();	// the addition of this line causes the corruption
                                        // even if you don't use it in the cpp side
  functional* _pFun;
};

--wrapper.cpp--

#include "wrapper.h"
#include "functional.h"
wrapper::wrapper(functional* pFun)
{
  _pFun = pFun;
  
  pExitFunction = &functional::set_one;
}
wrapper::~wrapper(void)
{
  (_pFun->*pExitFunction)();
}

This is the code of the functional class
--functional.h--

#pragma once

class functional
{
public:
  functional(void);
  ~functional(void);
  void set_one();
  int _iData;
};

--functional.cpp--

#include "functional.h"

functional::functional(void)
{
  _iData = 0;
}

functional::~functional(void)
{
}

void functional::set_one()
{
  _iData = 1;
}

Why does the stack get corrupted?
I'm really stuck on this one, so any pointers would help me a lot.

Learn from the mistakes of others, you may not live long enough to make them all yourself.

Re: Function pointer corrupts the stack or heap

Saurabh.Garg29-Jun-08 23:34

Re: Function pointer corrupts the stack or heap

29-Jun-08 23:34

Are you sure this code has a bug? I coudn't find any problem with the code so I decide to run it myself and it runs perfectly.

BadKarma wrote:
void (functional::*pExitFunction)(); // the addition of this line causes the corruption // even if you don't use it in the cpp side

This cannot be true because if you comment out this line then you will have to comment it in wrapper's constructor and destructor. If you do that than the class do nothing so it cannot corrupt memory.

-Saurabh

BadKarma29-Jun-08 23:49

BadKarma

29-Jun-08 23:49

Saurabh.Garg wrote:
Are you sure this code has a bug?

Unfortunatly, yes. I mean you're right, this code is valid(i have been using it for years in another project). But when i have ported it into an new project and after splitting the two classes the corruption takes place. Did you use two *.h and *.cpp file, or did't you implement them in a single file.

Saurabh.Garg wrote:
This cannot be true because if you comment out this line then you will have to comment it in wrapper's constructor and destructor. If you do that than the class do nothing so it cannot corrupt memory.

Correct, i commented the usage of the function pointer in the constructor and destructor. Maybe I shouldn't have showed them in this example.

Learn from the mistakes of others, you may not live long enough to make them all yourself.

Re:

Saurabh.Garg30-Jun-08 0:00

30-Jun-08 0:00

Well I tried with separate files, just like you mentioned, and I tried within a single file and this code runs perfectly fine.

Btw I am using VS 2008.

-Saurabh

Re:

BadKarma30-Jun-08 1:13

BadKarma

30-Jun-08 1:13

Saurabh.Garg wrote:
Btw I am using VS 2008.

I'm still using VS 2005.

But I have found a way to get it working.
When i replace the forward class declaration with in including of the class,
everything works fine?? Confused | :confused:

#pragma once
class functional;
#include "functional.h"
class wrapper
{
public:
  wrapper(functional* pFun);
  ~wrapper(void);
  
  void (functional::*pExitFunction)();	// the addition of this line causes the corruption
                                        // even if you don't use it in the cpp side
  functional* _pFun;
};

Maybe its a bug in the VS 2005 compiler, I'm really not getting this. OMG | :OMG:

Either way its working now,
thanks for the response anyway. Smile | :)

Learn from the mistakes of others, you may not live long enough to make them all yourself.

Re:

Saurabh.Garg30-Jun-08 3:31