|
You are assuming I'm able to reproduce the fault on my own system. Sadly, no. It is only this one particular beta tester who is experiencing the crash. The program runs fine on all my own computers (three different versions of Windows), and on every other person's computer who has ever run it.
The only thing I have to go on is the crash dump this particular beta tester sends me each time I send him a new build.
I think I have to bite the bullet and install the operating system he's using on one of my own systems. I can't see how I can possibly find this any other way, given that /MAPINFO:LINES is no longer supported by the linker in Visual Studio 2008.
I'll shut down my XP SP2 computer, pull out the hard drive and put in another hard drive I have that I don't mind blowing away, and install XP SP3 and VC++ 6 (which blessedly supports /MAPINFO:LINES. I just pray that I am able to reproduce the bug this way. I can't think what else it could be besides the unique platform he's using. I don't think any of my other beta testers are running XP SP3.
|
|
|
|
|
| Good luck. I think that you are right about reproducing the error so that you can identify it. Will the VC 6 debugger be compatible with your VS 2008 executable? Please do not read this signature.
|
|
|
|
|
It was originally written with VC++ 6 so it should work fine.
However I am freaking out because I can't find the VC++ 6 disk, and it's not on the MSDN site for some reason. They have VC++ 4.2 and then Visual Studio 2005. I don't know why they don't have VC++ 6. Does it go by some other name? I can't remember.
EDIT:
OMG it's gone - I can't believe it. I feel like going to the storage place to look through my old MSDN disks for it, but it's night and raining. I can't believe this.
http://blogs.msdn.com/publicsector/archive/2005/12/07/501169.aspxmodified on Friday, March 12, 2010 9:18 PM
|
|
|
|
|
Got it - PHEW!! That's a relief.
Saved again by my packrat instinct. I had it in storage.
Now to set up the hard drive...
|
|
|
|
|
Chris Losinger wrote: if you can't reproduce the problem on your own machine, you can try something like a map file[^]. or, there's always good old log files[^].
I was so excited when I read this article and saw there was a way to identify the exact line number where the crash occurred - until I learned that Microsoft has removed the /MAPINFO:LINES option starting in Visual Studio 2005. <<sob>> How could they do that?
At least now I know for sure the error is in InitInstance(). I just don't know WHERE in InitInstance().
|
|
|
|
|
permutations wrote: At least now I know for sure the error is in InitInstance(). I just don't know WHERE in InitInstance().
time to add a log file. (or, a bunch of AfxMessageBox calls).
|
|
|
|
|
Chris Losinger wrote: also, i ran into a similar problem when i apparently got a bit too aggressive with pre-compiled headers. i had moved everything i could think of into the PCH, and for some reason, this caused the ctor of a global std::list variable to explode on startup. i never could track down exactly why it was happening, so i simply turned off PCH for that configuration and it worked fine.
Forgot to mention... I'm not using PCH. I'd already turned this off.
|
|
|
|
|
Okay, my level of mystification is ever so slightly reduced thanks to a very excellent article here:
MFC under the hood[^]
I still don't know why the crash dump points at crt01.c, but apparently _tWinMain is actually called by AfxWinMain, and... (drum roll)... this function is calling my app's InitInstance() method, which is where the read access error is occurring.
I can't use the map file to tell exactly what line is causing the fault because Microsoft bizarrely removed the MAPINFO:LINES option from the linker starting with Visual Studio 2005. (I'm running Visual Studio 2008.) I can estimate the range of lines in which it's occurring by looking at function addresses in the map file. It's somewhere between the start of the InitInstance() method and my first call to StringCchCopy() - if I'm reading the map file correctly.
It's starting to look like I'll never find this unless I install XP3 and a compiler somewhere, and recreate the error so I can use the debugger to find it. Maybe I'll install it on my tablet - the one that makes a horrible grinding noise. (This appears to be the fan and not the hard drive, since replacing the hard drive didn't help.)
Actually, come to think of it, I have an extra hard drive for that computer because of the grinding noise. I can install XP SP3 clean there, install VC++ 6 (which blessedly can show line numbers in the map file) and find the error that way. It's kind of a pain, but I don't see what other choice I have.
Oh wait! Better yet. I have an extra hard drive for an notebook that is running properly. I bought a bigger one. I can use the smaller one to install the test system. I will do that.
|
|
|
|
|
I've got XP SP3 installed and I can't reproduce the crash. The program runs fine. I also found someone else with XP SP3 and it didn't crash for him, either.
There is apparently something unique about how this one beta tester sets up his systems (the crash happens on both his computers), but I have no idea what.
On the plus side, I'm installing VC++ 6 on the XP SP3 system and that has an option for map line numbers. I'll move the project over to that computer and rebuild. Then when I get the crash report back I'll know exactly what line is causing the problem.
|
|
|
|
|
Actually, I think I did finally reproduce the crash, though in a slightly different form.
Using VC++ 6 on XP SP3, when I do a full rebuild, I get a link error at the very end: "fatal error LNK 1561: entry point must be defined". If I then do an incremental build it links fine and I'm able to run the program.
But this link error sounds suspiciously like the error my beta tester gets. When he runs the program, it fails on the program entry call to _tWinMain, and it's a read error. It's probably trying to read the program entry point and finding a null pointer.
I think that if I'm able to solve my link problem, I'll also solve the beta tester's crash problem. It's probably one of two things: either I set up my DLL incorrectly and that is causing confusion about entry points (I can't even remember how I did this - I'm going over it all again), or (more likely) I have a buffer overrun in one of the very first variables I set up in the program that is wiping out the program entry point. Buffer overruns are always such a joy to hunt for (not).
|
|
|
|
|
I'm stuck. I'm only getting this link error in Release mode. In Debug mode it's fine. And I've gone over everything carefully and can see no problems. I've also included error checking everywhere.
|
|
|
|
|
Hi,
I know that to manage the GUI of the application a separate thread have to send/post messages to the main thread to let him do everything.
But, please, help me to understand if this is possible:
It is possible to create, manage and finally destroy a window (or a dialog) all in a separate thread?
I mean a simple dialog like a custom message box dialog, or input dialog.
It can be enough for mo to display some graphic into a little DC that I like to manage with a separate thread, like an external object.
Thanks...
Russell
|
|
|
|
|
I know an application
whose views will be drawn by separate event-controlled threads 
I know an application
whose worker-threads do show topmost windows with a progress control
Yes, it is possible.virtual void BeHappy() = 0;
|
|
|
|
|
| It should be possible. > The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Hy everyone . I search for long time a class , derived from CListCtrl ( MFC ) , which ,
1.Order items ascendent and descendent
2.Every column ( except first one ) may be hidden from right-click menu
3.Store column order and sort order into windows registry
4.GetItemData and SetItemData must be disponible !!!!
5.Compatible in VC6
I found a class which is very close to my request : CListCtrlEx[], but have one little problem : could not use SetItemData and GetItemData ...  ( I transform this project and class for VC6 , if anyone want , I can spare it ! ).
May be , anyone have some kind of class , and could shared with me ... ( If must , I even could pay for that ! )
Thank for your attention !
|
|
|
|
|
Did you see Hans Dietrich's XListCtrl class?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I found a class that approach my needs here , but , for now , is not sorting items ... thanks for hint , I will look over XListCtrl.
|
|
|
|
|
mesajflaviu wrote: ...but , for now , is not sorting items...
Does the control have the LVS_SORTASCENDING or LVS_SORTASCENDING style?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
No , does not have LVS_SORTASCENDING or LVS_SORTASCENDING style , I can set that , but does have any different of ? Because I like to have sort capability on LVN_COLUMNCLICK message , to sort any direction ... and that is not very simple ( for me , at least ) ... 
|
|
|
|
|
CListCtrlEx uses ItemData for its internal logic. Just make the structure ITEM_DATA public/protected and use this logic in an inherited class to retrieve/set the ItemData:
ITEM_DATA* pItemData = reinterpret_cast<ITEM_DATA*>(GetItemData(index));
LPARAM itemData = pItemData->m_lParam;
pItemData->m_lParam = 10;
P.S. CGridListCtrlEx - Grid Control Based on CListCtrl[^]modified on Sunday, March 14, 2010 8:40 PM
|
|
|
|
|
Snakefoot wrote: CListCtrlEx uses ItemData for its internal logic. Just make the structure ITEM_DATA public/protected and use this logic in an inherited class to retrieve/set the ItemData:
ITEM_DATA* pItemData = reinterpret_cast(GetItemData(index));LPARAM itemData = pItemData->m_lParam;pItemData->m_lParam = 10;
P.S. CGridListCtrlEx - Grid Control Based on CListCtrl[^]
Good idea , I will try , but how can I make a public/protected structure ITEMDATA* in my class ? What you say : good question too  , sorry , I'm not very advanced ... 
|
|
|
|
|
Since you already have made modifications directly to the CListCtrlEx class to make it compile with VC6, then you can also make the extra modification of changing all private-keywords to protected-keywords in its header file.
|
|
|
|
|
Hello.
I have simple console application written in c++ and compiled on my computer running Windows 7. The exe is working as wanted on my mashine but not in the same way on another computer running Windows 7?
Why does that happen? Is it because Visual Studio installs additional components in my computer which the other PC do not have?
Thanks
|
|
|
|
|
corrosion190 wrote: Why does that happen? Is it because Visual Studio installs additional components in my computer which the other PC do not have?
Probably. Depending on your project settings, you may or may not need to install VC++ runtime dll's on the target machine. In particular, if your project uses MFC, project settings specifying 'Use MFC in a Shared DLL' means that the MFC runtime will be needed. (Of course, your program may require other system dll's to be specifically linked, as well; it all depends on what you're doing. In general, though, for simple programs, it's the MFC dependency that trips people up.)
The simplest way to reduce the number of dependencies is to compile with 'Use MFC in a Static Library'; this will remove the MFC requirement. To get a complete picture of your project's requirements, download the Dependency Walker[^].
For more info, see this[^]. Note in particular the section on 'Understanding dependencies'.L u n a t i c F r i n g e
|
|
|
|
|
I tried compiling with "Use MFC in a Static Library" and I got those errors:
Cpp error LNK2019: unresolved external symbol __imp__ShowWindow
Cpp error LNK2019: unresolved external symbol __imp__GetWindowTextA
Cpp error LNK2019: unresolved external symbol __imp__GetWindowTextLengthA
Cpp error LNK2019: unresolved external symbol __imp__GetForegroundWindow
Cpp error LNK2019: unresolved external symbol __imp__GetAsyncKeyState
Cpp error LNK2019: unresolved external symbol __imp__GetKeyState
Cpp fatal error LNK1120: 6 unresolved externals
Cpp warning LNK4199: /DELAYLOAD:OleAcc.dll ignored; no imports found from OleAcc.dll
Cpp warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
The same result with "Use MFC in a Shared DLL"..
When I try with Use Standard Windows Libraries I get only one warning: LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
