Debugging release mode

[learnyourabc]

I have a legacy release mode mfc application at customer site that
generates a exception at some address. For some reason, I am not able
to debug the system there and is not able to simulate the error on my
pc.Lets say I am able to get the address that this exception occurs.
Will It be too late to debug it now by generating the pdb files as
shown below

First go to Project->Settings, select the release build, then:

On the C/C++ tab for all librarys, DLLs and executables, in the
general category, set Debug Info to Program Database. This tells the
compiler to generate debug information.
On the link tab for all DLLs and executables, in the general category,
put a check mark beside Generate Debug Info. This tells the linker to
collate debug information into .pdb files. The linker also puts the
name of the .pdb file in the executable, so the debugger can find it.
That's why your executable gets a bit bigger. Dumpbin /headers will
show you that information.

If I were to have the same source code and project that generated that
exe file and
only now try to generate debug information or the pdb. This exe will
be different from the one at the customer's site right?

Ctrl G to goto that address given will it be the same instruction or
statement.
Thanks for any help rendered.

[Guido Franzke]

Hi.
As far as I know, you must keep the original source, pdb file and object
files when linking the release that is installed on your customers computer.
Then you are able to debug the release. I think the debugger compares the
exe with the actual pdb and object files. So you must reinstall the new
version of your newly compiled programme, then you can debug it again.
I use a mini dump in my apps so that a dump file is created at the customer.
If the app crashes, the minidump is written and the customer sends it to me,
so I can directly see where and why the programme has crashed.

Regards, Guido

Post by learnyourabc
I have a legacy release mode mfc application at customer site that
generates a exception at some address. For some reason, I am not able
to debug the system there and is not able to simulate the error on my
pc.Lets say I am able to get the address that this exception occurs.
Will It be too late to debug it now by generating the pdb files as
shown below
On the C/C++ tab for all librarys, DLLs and executables, in the
general category, set Debug Info to Program Database. This tells the
compiler to generate debug information.
On the link tab for all DLLs and executables, in the general category,
put a check mark beside Generate Debug Info. This tells the linker to
collate debug information into .pdb files. The linker also puts the
name of the .pdb file in the executable, so the debugger can find it.
That's why your executable gets a bit bigger. Dumpbin /headers will
show you that information.
If I were to have the same source code and project that generated that
exe file and
only now try to generate debug information or the pdb. This exe will
be different from the one at the customer's site right?
Ctrl G to goto that address given will it be the same instruction or
statement.
Thanks for any help rendered.

[learnyourabc]

Just as I expected. The program was compiled using default release
mode and released to the customer with no proper logging or minidumps
or linked with debug info and I can't seem to get the same problem
over at my pc. How can I debug this to source?? I am not able to
reinstall the new version of my newly compiled source.

[Guido Franzke]

I've had the same problem once. Many MVPs answerd me that there's no chance
to get the debug info and pdb file back if not saved.
Sorry.

But if someone knows, let me know too!
Regards, Guido

Post by learnyourabc
Just as I expected. The program was compiled using default release
mode and released to the customer with no proper logging or minidumps
or linked with debug info and I can't seem to get the same problem
over at my pc. How can I debug this to source?? I am not able to
reinstall the new version of my newly compiled source.

[Oleg Starodumov]

Post by Guido Franzke
As far as I know, you must keep the original source, pdb file and object
files when linking the release that is installed on your customers computer.
Then you are able to debug the release. I think the debugger compares the
exe with the actual pdb and object files.

Object files are not needed. You need the executable, its .pdb file, and sources.

Oleg

[Oleg Starodumov]

Post by learnyourabc
On the C/C++ tab for all librarys, DLLs and executables, in the
general category, set Debug Info to Program Database. This tells the
compiler to generate debug information.
On the link tab for all DLLs and executables, in the general category,
put a check mark beside Generate Debug Info. This tells the linker to
collate debug information into .pdb files. The linker also puts the
name of the .pdb file in the executable, so the debugger can find it.
That's why your executable gets a bit bigger. Dumpbin /headers will
show you that information.

I guess you use VC6, so you would need the following options:
Compiler: /Zi
Linker: /debug /debugtype:cv /pdb:yourapp.pdb /pdbtype:con /opt:ref

Note /opt:ref - it is important to prevent executable size from growing.

Post by learnyourabc
If I were to have the same source code and project that generated that
exe file and only now try to generate debug information or the pdb.
This exe will be different from the one at the customer's site right?

If you also have the same build tools, it would be close.

Post by learnyourabc
Ctrl G to goto that address given will it be the same instruction or
statement.

It could be close enough to be able to debug (you could look at the same address
in the original executable and match the disassembly you see with the disassembly
in your new executable, and thus find the problematic code even if it is shifted
to some degree). Try to build it and compare with the original version.
And it even could be possible to debug a minidump with the new executable.

If the executables will differ, try to build without debug information options
but with .MAP file generation enabled, and use .MAP file to find the place.

[learnyourabc]

On Jun 23, 3:28 am, "Oleg Starodumov" <com-dot-debuginfo-at-oleg>

Post by Oleg Starodumov

Post by learnyourabc
On the C/C++ tab for all librarys, DLLs and executables, in the
general category, set Debug Info to Program Database. This tells the
compiler to generate debug information.
On the link tab for all DLLs and executables, in the general category,
put a check mark beside Generate Debug Info. This tells the linker to
collate debug information into .pdb files. The linker also puts the
name of the .pdb file in the executable, so the debugger can find it.
That's why your executable gets a bit bigger. Dumpbin /headers will
show you that information.

Compiler: /Zi
Linker: /debug /debugtype:cv /pdb:yourapp.pdb /pdbtype:con /opt:ref
Note /opt:ref - it is important to prevent executable size from growing.

Post by learnyourabc
If I were to have the same source code and project that generated that
exe file and only now try to generate debug information or the pdb.
This exe will be different from the one at the customer's site right?

If you also have the same build tools, it would be close.

Post by learnyourabc
Ctrl G to goto that address given will it be the same instruction or
statement.

It could be close enough to be able to debug (you could look at the same address
in the original executable and match the disassembly you see with the disassembly
in your new executable, and thus find the problematic code even if it is shifted
to some degree). Try to build it and compare with the original version.
And it even could be possible to debug a minidump with the new executable.
If the executables will differ, try to build without debug information options
but with .MAP file generation enabled, and use .MAP file to find the place.
--
Oleg
[VC++ MVPhttp://www.debuginfo.com/]

Thanks a lot will try this out and see if I can match section of the
assembly code with the newly generated one with pdb generation. I am
looking at this really old but fabulous book Debugging Applications by
John Robbins from Microsoft Press and there's a newer one on .net. As
stated in the book all applications should be released with debug
symbol info cause it's plain irresponsible to do otherwise. Why
didn,t microsoft set the default release for VS to generate the pdb
file or map file in the first place??

[Oleg Starodumov]

Post by learnyourabc
Thanks a lot will try this out and see if I can match section of the
assembly code with the newly generated one with pdb generation. I am
looking at this really old but fabulous book Debugging Applications by
John Robbins from Microsoft Press and there's a newer one on .net. As
stated in the book all applications should be released with debug
symbol info cause it's plain irresponsible to do otherwise. Why
didn,t microsoft set the default release for VS to generate the pdb
file or map file in the first place??

Since VC2002, release builds generate debug info by default.
VC6 was released a bit before the more or less modern
debugging approaches became widespread, and had its ancestry
in times when disk space and buld time were more important.

Oleg

[learnyourabc]

Post by Oleg Starodumov
Since VC2002, release builds generate debug info by default.
VC6 was released a bit before the more or less modern
debugging approaches became widespread, and had its ancestry
in times when disk space and buld time were more important.
Oleg

At least it's comforting to know that I do not have to deal with this
issue for newer .net apps for VC2002 and above. but there's still a
lot of legacy windows apps out there.

[learnyourabc]

I have generated the map files for my app.

From feedback from user,

I got the following standard MFC application error that goes like
this

"Application has encountered a problem and needs to close. We are
sorry for the inconvenience."

When I click on the debug button I get the following error
message(The VS debugger did not show up it should have been removed
earlier)

"Application Error 0xC0000096 occur at the application location
0x08e31161"<----------???

What is causing the above Privileged Instruction exception
error(0xC0000096)??? my application does not run into application
location 0x08e31161????

Any help would be much appreciated

[learnyourabc]

I have VC6, appverifier and the same old .exe that I want to debug.
How do I run the appverifier with the debugger for the .exe???
Following the instructions just add application to application
verifier 3.3 then click save error

"The tests that you have selected requires a debugger"

Any step by step instruction of what is meant by running the
application under the debugger?? Am I suppose to open the .exe in the
debugger??
Can anyone please enlighten me thanks.

[Oleg Starodumov]

Post by learnyourabc
I have VC6, appverifier and the same old .exe that I want to debug.
How do I run the appverifier with the debugger for the .exe???
Following the instructions just add application to application
verifier 3.3 then click save error
"The tests that you have selected requires a debugger"
Any step by step instruction of what is meant by running the
application under the debugger?? Am I suppose to open the .exe in the
debugger??
Can anyone please enlighten me thanks.

The message is actually not an error, only a notification.

Simply run the application under debugger. If you do not have a project
for it, open the .exe file (File | Open Workspace).

When AppVerifier detects a problem, it will usually raise an exception
or a hard-coded breakpoint. After that, it usually makes sense to check
the call stack to see where the problem occurred. In your case (VC6),
it might not be easy to do it (symbols setup can be complicated),
so you might consider using WinDbg (only as a nonintrusive addition to VC6,
when needed), as shown here:
http://www.debuginfo.com/articles/easywindbg.html

Also check that your application does not have catch(...) statements
(catch of specific exception types are OK, only catch(...) that attempts
to catch everything is a problem - it will make AppVerifier/PageHeap
less effective).

Oleg

[learnyourabc]

Back to the problem of
"Application Error 0xC0000096 occur at the application location
0x08e31161"<----------??? privilege instruction
Could the above error be due to an invalid function pointer that jumps
out to some invalid address outside of the app leading to the
privilege instruction error (nowhere in the program did I call _inp or
_out)

This error seems to occur inside the portion of code that spawns off
another scheduling thread(AutoDownloadThread).

Can you pass a CDocument derived pointer into the AfxBeginThread()???
If yes, is it only for static or non-MFC variables or functions. What
if you update the Gui from the CDocument passed over to this thread?

void CMyAppDoc::OnSpawnthread()
{
//......................................
pAutoThread = AfxBeginThread(AutoDownloadThread,this);
}
UINT CMyAppDoc::AutoDownloadThread(LPVOID lpvData)
{
CMyAppDoc *pThis = (CMyAppDoc*)lpvData;
//..........................................................................
pThis->CStatusDialog->UpdateWindowText()............//update
the Gui on a dialog or view
pThis->doallsortsofGUIstuff();
//.....................................................
}

It seems to run OK most of the time and I did not get the error on my
pc ?? Could this be causing the error?

How can one debug this? Application Error 0xC0000096 ??address
location 0x08e31161 is outside any my app in any of the map files
generated.

Thanks for any help provided.

[Oleg Starodumov]

Post by learnyourabc
Back to the problem of
"Application Error 0xC0000096 occur at the application location
0x08e31161"<----------??? privilege instruction
Could the above error be due to an invalid function pointer that jumps
out to some invalid address outside of the app leading to the
privilege instruction error (nowhere in the program did I call _inp or
_out)

Yes, see also below.

Post by learnyourabc
This error seems to occur inside the portion of code that spawns off
another scheduling thread(AutoDownloadThread).
Can you pass a CDocument derived pointer into the AfxBeginThread()???
If yes, is it only for static or non-MFC variables or functions. What
if you update the Gui from the CDocument passed over to this thread?

It is dangerous (and is not allowed) to use MFC GUI objects from threads
that did not create them. So you should be on the right way.

Another typical reason why you can see an exception like that is heap corruption
(e.g. buffer overwrite that corrupts a vtable pointer of a C++ class stored
on the heap). AppVerifier/PageHeap should help to detect such situations.

Yet another reason could be stack corruption, but less likely with the symptoms
you see.

Oleg

[learnyourabc]

I got a crash.dmp user dump file from the user but is not able to link
to source using windbg.

I included the Crash Report below in my app so that I can debug the
error.
http://www.codeproject.com/debug/XCrashReportPt3.asp
I compiled the MyApp.exe with debug info enabled and pdb and map
files.
I renamed it to MyAppVer1.exe and passed to the user to run it and
waiting for the same crash to occur.
I got a crash.dmp user dump file from the user but is not able to link
to source using windbg.
Steps taken:
I copied the crash.dmp and errorlog.txt file to my C:\MyApp\release
directory containing the MyApp.exe executable. (do I need the renamed
file??)
Open the crash.dmp in windbg
.sympath C:\MyApp
.exepath C:\MyApp
.srcpath C:\MyApp
.ecxr

I cannot see the source codes or statement that caused the error.What
do I need to do?

[learnyourabc]

Anyway have found the bug and resolve this using the errorlog.txt
address of the unhandled exception and the map file generated.Thanks
for the help.