|
I've noticed heaps of people use this technique, but it's not necessary to go to all this trouble. There is nothing to stop you from making a release build with debug info. All you need to do is enable it in the compiler settings in the compiler and linker tabs. Once this is done, any time you release your software you just stash the .PDBs somewhere. There is even a utility that comes with WinDBG called "symstore" you can use to manage the .PDBs. Once you've got a .PDB you can use a debugger to get all the information the .MAP file technique can produce but easier (and more info that .MAP files can't even dream of); just use the debugger as you normally would or get a crash dump and use WinDBG to do postmortem analysis. There really is no reason for this overly complex and convoluted .MAP file technique.
Steve
|
|
|
|
|
In my case, with 10000+ installations all over the country, it's a lot easier for the (few) people with problems to read out and inform me about the reported crash address than sending me debug files.
A lot of the users of my program aren't very good at doing different stuff than the are used to. (Accountants and such.)
If the crash happened for a programmer or in the near environment, then it would be a completely different story...
As always, the problem is the users... 
Life would be a lot easier without them. 
Life would also be poorer... 
|
|
|
|
|
kakan wrote: inform me about the reported crash addr
This technique is flakey. For example, if the crash is in a DLL the DLL may not be mapped to the same location on all machines as DLLs are rebased if need be. Even on two machines on which they would normally be mapped at the same address running an application that installs a global hook using the SetWindowsHookEx may be enough for it not to be if the DLL is loaded and the hook DLL happens to overlap the DLLs preferred load address. If the crash is in the EXE rebasing is not a problem as EXEs are always loaded at their preferred base address.
Even so, if you've only got a crash address, the following technique will get the symbol name from an address using WinDBG just like with the MAP file technique:
1. Debug the .EXE using WinDBG.
2. Break into the debugger.
3. Enter the following command: "ln 0x01001000". Where the number is the crash address. He's the output from doing this in notepad:
0:000> ln 0x01001000
(01001000) notepad!_imp__RegQueryValueExW | (01001004) notepad!_imp__RegCloseKey
Exact matches:
notepad!_imp__RegQueryValueExW = <no type information>
At a previous job I used to do a lot of postmortem debugging. I actually used to use the map file technique. I wrote an application that used to get a symbol name from a map file and an address and could even make a stack trace from a Dr.Waston log (not a dump) and a MAP file. That was before I discovered it was "the hard way".
Steve
|
|
|
|
|
OK, now I see! 
Thanks for the tip! I will most certainly use it!
|
|
|
|
|
_RecordsetPtr rs = m_pConn->Execute("select * from businfo",NULL,0);
rs->Save((IDispatch*)m_pStm,adPersistXML); //0k
_bstr_t str = m_pStm->Charset;
str = m_pStm->ReadText(adReadAll);
int k = str.length(); //ok
_RecordsetPtr rs1;
rs1.CreateInstance(__uuidof(Recordset));
rs1->Open((IDispatch*)m_pStm,"",adOpenForwardOnly,adLockReadOnly,adCmdFile );//error,I don't know why
contact me :xiaolinzi0941@hotmail.com
|
|
|
|
|
I don't know what technologies you using or what types your variables are. I assume m_pStm is an IStream. Your cast to IDispatch* worries me: this can't be an up-cast as IStream doesn't derive from IDispatch; it's possible that it's a down-cast but I find that unlikely. I suspect this cast isn't valid and if this is the case this is a perfect opportunity for me to rant about the evils of the C-style cast:
C-style casts; just say no. If you use this instead you will have more type checking at compile time which will catch many bad casts (but not all):
rs->Save(static_cast<IDispatch*>(m_pStm), adPersistXML);
With this style of casting you can't cast between unrelated types; which is almost always the programmer's intent.
Steve
|
|
|
|
|
You don't cast COM interfaces like this (the exception is that inside the implementation you may do so). Use IUnknown::QueryInterface for this purpose.
Steve
|
|
|
|
|
m_pStm is an instance of _StreamPtr,and save works,I just don't know how to open a Stream with Recordset::Open()
contact me :xiaolinzi0941@hotmail.com
|
|
|
|
|
I understand and know how to use the command begin trans, commit and also rollback in MS SQL Server. However, inside the MFC C++ coding, how could I issue all these commands to the database(in MS SQL CE form)?
Please help and thanks =)
Ting
|
|
|
|
|
|
See here.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
I'd like to write come code to change the mouse properties for right-handed to left-handed, but I don't know how can I do that. Any clue or artical on internet?
|
|
|
|
|
Perhaps SwapMouseButton will help you.
Steve
|
|
|
|
|
How to create a CBitmap object from a bitmap file?
.
|
|
|
|
|
|
CBitmap m_Bit;
m_Bit.Attach((HBITMAP)::LoadImage(NULL,Filename,
IMAGE_BITMAP,0,0,
LR_LOADFROMFILE|LR_CREATEDIBSECTION));
|
|
|
|
|
Hi,
Can't I create it using Bitmap Rescorce i.e. IDB_BITMAP1.
Thanks,
Aniket
|
|
|
|
|
try
CBitmap m_Bit;
m_Bit.LoadBitmap(IDB_BITMAP1);
|
|
|
|
|
Hi,
Thanks for your reply.
CBitmap m_Bit;
m_Bit.LoadBitmap(IDB_BITMAP1);
HBITMAP hSourceBitmap = (HBITMAP) m_Bit;
Is this a correct way?
Aniket
-- modified at 5:00 Thursday 11th May, 2006
|
|
|
|
|
why you use HBITMAP hSourceBitmap you can use m_Bit.m_hObject and i think you dont need to hbitmap handle
|
|
|
|
|
|
How can i hide a procees showing itself in processes list in windows xp.
is it possible.??
|
|
|
|
|
Why would you want to?
100% natural. No superstitious additives.
|
|
|
|
|
I need this for a project that project requires that program will run as service and service listening to some port. it can run any other application using some commands. and new processes that are started through service shud not be seen in processes list
i just want to know is it possible to hide a process from processes list.
|
|
|
|
|
AFAIK, that is not possible, unless you write some kernel extension. This is what rootkits normally do, and is not considered "kosher". It's also a bad idea to hide processes like that, in case you need to kill a process manually.
Why the tough restriction on process visibility, if I may ask?
--
100% natural. No superstitious additives.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
