Windbg is not showing all variable value in crash dump.

[Anand Choubey]

Hi,

I am facing a strange thing in windbg and crash dump analysis.

I wrote a test application to learn windbg.
In this application, I started 3 same threads but only one gets
crashed and i created crash dump minidumpwritedump with
MiniDumpWithDataSegs flag.
When i analyze the crash dump tried to see remaining 2 threads' (which
are not crashed) stack variable value then windbg does not show
anything.
windbg shows variable i and lpParam data but not pData and other
variable.
I could not understand where is mistake. please let me know.
DWORD WINAPI ThreadProc( LPVOID lpParam )
{
HANDLE hStdout;
PMYDATA pData;

MYDATA md;
md.val1 = 1;
md.val2 = 100;
TCHAR msgBuf[BUF_SIZE];
size_t cchStringSize;
DWORD dwChars;

hStdout = GetStdHandle(STD_OUTPUT_HANDLE);
if( hStdout == INVALID_HANDLE_VALUE )
return 1;

// Cast the parameter to the correct data type.

pData = (PMYDATA)lpParam;

while(1)
{
static int i = 0;
if(i >= 1)
{
if(1 == pData->val1)
{
int *p = NULL;
*p = 1;
printf("%p", p); //<<<<<<<<<<<< Here crashed
}
//fun();
}
::Sleep(1000);
i++;
}

// Print the parameter values using thread-safe functions.

StringCchPrintf(msgBuf, BUF_SIZE, TEXT("Parameters = %d, %d\n"),
pData->val1, pData->val2);
StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);

// Free the memory allocated by the caller for the thread
// data structure.

::Sleep(100000);
printf("after sleep");

HeapFree(GetProcessHeap(), 0, pData);

return 0;
}

Regards,
Anand Choubey

[Nathan Mates]

In article <54a95bc2-df2d-4f1d...@e1g2000pra.googlegroups.com>,

Anand Choubey <anand....@gmail.com> wrote:
>windbg shows variable i and lpParam data but not pData and other
>variable.

Did you compile for debug or release? Not seeing local variables is
normal for release, because the optimizer is free to do what it wants
with them. This is not a bug. If you want easy debugging, run
debug. If you want speed, run release. You can google to find out
*how* debug and release differ. From that, you should think a bit to
figure out the *why* debug and release differ.

If you want to debug release, it's a skill you've got to learn-- in
fact, it's more of an art than a "look at the locals window." Ability
to read x86 assembly helps, a lot. Ability to look at source code and
x86 disassembly to understand what it's doing is even better. This
isn't something you'll pick up overnight. It takes time and practice.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

[Anand Choubey]

Hi,

Thanks Nathan!!!
It was my mistake. Application was built in RELEASE.

I built application in debug and i checked crash dump. This time
shows value of every variable
except "pData" which is thread parameter.
May I know that why value of "pData" is not being displayed. Is there
any restriction for thread parameter?

Regards,
Anand Choubey

On Feb 13, 12:04 am, nat...@visi.com (Nathan Mates) wrote:
> In article <54a95bc2-df2d-4f1d-a6b7-2de2dcf3e...@e1g2000pra.googlegroups.com>,

> Anand Choubey  <anand.chou...@gmail.com> wrote:
>
> >windbg shows variable i and lpParam data but not pData and other
> >variable.
>
>    Did you compile for debug or release? Not seeing local variables is
> normal for release, because the optimizer is free to do what it wants
> with them. This is not a bug. If you want easy debugging, run
> debug. If you want speed, run release. You can google to find out
> *how* debug and release differ. From that, you should think a bit to
> figure out the *why* debug and release differ.
>
>    If you want to debug release, it's a skill you've got to learn-- in
> fact, it's more of an art than a "look at the locals window." Ability
> to read x86 assembly helps, a lot. Ability to look at source code and
> x86 disassembly to understand what it's doing is even better. This
> isn't something you'll pick up overnight. It takes time and practice.
>
> Nathan Mates
> --

> <*> Nathan Mates - personal webpagehttp://www.visi.com/~nathan/ 
> # Programmer at Pandemic Studios --http://www.pandemicstudios.com/