|
oh ya! i got my problem resolved. actually i have called "continue" in my property page instance.
thanks for the co-operation.
jiteen
|
|
|
|
|
Grats. It's always very satisfying to find and fix tricky bugs.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
hi all,
i hav given my application to client and there its failing, but in my system its working fine.
please give me the solution where exactly its failing?
Regards,
Prashanth.v
|
|
|
|
|
maybe your application need to dll files that are only in your system
|
|
|
|
|
no.
every thing is ok, but still its failing.
|
|
|
|
|
Are you sure that your problem is not dll files
well can you show error
|
|
|
|
|
without giving any error, it is simply disappering.
thats what the information got from my client.
|
|
|
|
|
I guess you use one service that isnt in another system,
or do you use printer in your system
|
|
|
|
|
voorugonda prashanth wrote: my application to client and there its failing, but in my system its working fine.
Could you list the failure events or error messages here? Try to get the screenshots or the logs in the EventLogs...
Maxwell Chen
|
|
|
|
|
Set up the clients system to create crash dumps:
1. "Start->Run".
2. Type in "drwtsn32" and press enter.
3. Select crash dumps type ("Full" or "Mini").
4. Make sure "Create Crash Dump File" is selected.
When a crash occurs a dump will be generated (note: only the dump for the latest crash is kept). The full path of the dump is in the "Crash Dump" edit box. Get them to send you this file. Open it with WinDBG using "File->Open Crash Dump".
I hope (for your sake) you've built the release builds with debug information and kept the .PDBs. The first time you attempt this procedure and realise you haven't got .PDBs for your release builds you will see the wisdom in always generating and keeping them (in a symbol server is best).
Steve
|
|
|
|
|
hi steve,
what is WinDBG here? is it a tool??
how can i get that tool??
Thank u all.
|
|
|
|
|
Down load it from Microsoft. Google for "Debugging Tools for Windows".
Steve
|
|
|
|
|
This article has save my b*tt at several occations. I have an application that's installed on 10000+ PC's, and a couple of times a year, it crashes. This far, I have been able to find out the cause (and the solution) of the problem by following this article.
http://www.codeproject.com/debug/mapfile.asp[^]
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
