persistent crash on tester's computers that I can't reproduce
-
Those are good points about the environment. Something like this would explain how it could be something specific about his system that isn't fixed by booting into Safe mode or not running Startup programs. I don't think it's date-format-related or it would be crashing on the computer of the Australian guy who's been testing the program, too. He's tried it on multiple systems with no problems. I check return codes for everything - I went over every line of the startup code again. Isn't the recent file list always stored in the registry for XP and above? My program targets XP and above. Anyway, I know it is on his system because my crash dump report includes the registry settings. I use this statement to enable and load the MRU files:
LoadStdProfileSettings(4);
My program does do a lot with input and output, and the InitInstance function mainly figures out paths for input and output. The input path is wherever the executable is. If the path ends up more than 260 characters, the program will put up an error message and terminate. Output is a subdirectory of MyDocs, which is created if it's not found. I check every return code and terminate cleanly if something goes wrong. I've traced through all the filename/path stuff in the debugger and it's working correctly. He sent me some system specs from a diagnostic program he runs. I should look at it more carefully.
I am not familiar with
LoadStdProfileSettings(4);. What does it return when there aren't any MRU files (in registry or where ever they get stored)? one more typical mistake: one cannot store a file in a folder that does not yet exist. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
I am not familiar with
LoadStdProfileSettings(4);. What does it return when there aren't any MRU files (in registry or where ever they get stored)? one more typical mistake: one cannot store a file in a folder that does not yet exist. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
It has no return code. Here's what Microsoft says about it: http://msdn.microsoft.com/en-us/library/xbkh2k4h.aspx[^]
CWinApp::LoadStdProfileSettings Call this member function from within the InitInstance member function to enable and load the list of most recently used (MRU) files and last preview state.
void LoadStdProfileSettings(
UINT nMaxMRU = _AFX_MRU_COUNT
);I definitely create the output folder before I store anything in it.
-
I'm at my wit's end trying to track down a crash problem that only one person is seeing, but he sees it on BOTH his computers. I can't reproduce it, even after installing the same OS he's running (XP SP3), and neither can any of my other beta testers. I'm using XCrashReport to produce minidumps that he can send me when it crashes. It usually crashes on this line in InitInstance, which checks if there is a recently used file to load:
if (m_pRecentFileList->m_nSize > 0 && !m_pRecentFileList->m_arrNames[0].IsEmpty())
I have gone through the code in InitInstance line by line and I don't see any problems. Every global variable is initialized. Return codes are checked for every function call. I changed all my strcpy's to strncpy to make sure there aren't any overflows. Weirder yet, when I compile the program - exact same code, line-for-line - in VC++ 6 rather than Visual Studio 2008 - he doesn't get the crash. SAME CODE!! The only difference is that with Visual Studio 2008 I link MFC in statically because I'm running Windows 7 (64-bit) and he doesn't have the DLLs on XP. I installed XP SP3 on a computer and did not get the crash. Two other testers have XP SP3 and do not experience the crash. I asked him to use msconfig to disable Startup programs. He did, and it still crashed. I asked him to use msconfig to reboot into diagnostic mode. He did, and it still crashed. Doesn't that suggest it's my code and not a conflict with something on his system? But if it's such a bad bug, then why doesn't even one other person see it? I don't know what to do at this point. I can't find it if I can't reproduce it. And not only can I not reproduce it, no one else who has run the beta can reproduce it. I'm tempted to ignore the problem on his system and move on, but what if I release the program and it starts crashing on 10% of systems? How do I find this bug??? Any help would be greatly - hugely - appreciated. I've been working on this for a week, and I'm out of ideas.
I believe it is related to Heap Corruption. Most probable reason is Buffer overrun. Check for memory copy, memory concatenation etc in our code in that flow. Some where in the code, you are using more memory than allocated. These errors are hard to detect and crash on those machines, where it wont get that memory location, which is overrun from the allocation, because it might have benn already reserved.
Величие не Бога может быть недооценена.
-
I'm at my wit's end trying to track down a crash problem that only one person is seeing, but he sees it on BOTH his computers. I can't reproduce it, even after installing the same OS he's running (XP SP3), and neither can any of my other beta testers. I'm using XCrashReport to produce minidumps that he can send me when it crashes. It usually crashes on this line in InitInstance, which checks if there is a recently used file to load:
if (m_pRecentFileList->m_nSize > 0 && !m_pRecentFileList->m_arrNames[0].IsEmpty())
I have gone through the code in InitInstance line by line and I don't see any problems. Every global variable is initialized. Return codes are checked for every function call. I changed all my strcpy's to strncpy to make sure there aren't any overflows. Weirder yet, when I compile the program - exact same code, line-for-line - in VC++ 6 rather than Visual Studio 2008 - he doesn't get the crash. SAME CODE!! The only difference is that with Visual Studio 2008 I link MFC in statically because I'm running Windows 7 (64-bit) and he doesn't have the DLLs on XP. I installed XP SP3 on a computer and did not get the crash. Two other testers have XP SP3 and do not experience the crash. I asked him to use msconfig to disable Startup programs. He did, and it still crashed. I asked him to use msconfig to reboot into diagnostic mode. He did, and it still crashed. Doesn't that suggest it's my code and not a conflict with something on his system? But if it's such a bad bug, then why doesn't even one other person see it? I don't know what to do at this point. I can't find it if I can't reproduce it. And not only can I not reproduce it, no one else who has run the beta can reproduce it. I'm tempted to ignore the problem on his system and move on, but what if I release the program and it starts crashing on 10% of systems? How do I find this bug??? Any help would be greatly - hugely - appreciated. I've been working on this for a week, and I'm out of ideas.
Are you in a position to be able to setup a remote debugging connection? This allows you to step through the code on the target computer using the debugger on your PC. There are some hoops to jump through to set it up, but it may be invaluable in helping to track down the root cause of the issue.
If you vote me down, my score will only get lower
-
Are you in a position to be able to setup a remote debugging connection? This allows you to step through the code on the target computer using the debugger on your PC. There are some hoops to jump through to set it up, but it may be invaluable in helping to track down the root cause of the issue.
If you vote me down, my score will only get lower
I've never done this and don't know how. What do you have to do to set it up?
-
I've never done this and don't know how. What do you have to do to set it up?
I would recommend you do a search on the microsoft site for remote debugging in relation to the development platform your using. (Actually a straight google search for "remote debugging" should turn up what you need) As the implementation of this has varied slightly over the years, I cannot give any direct description on how to perform it for your environment.
If you vote me down, my score will only get lower
-
I'm at my wit's end trying to track down a crash problem that only one person is seeing, but he sees it on BOTH his computers. I can't reproduce it, even after installing the same OS he's running (XP SP3), and neither can any of my other beta testers. I'm using XCrashReport to produce minidumps that he can send me when it crashes. It usually crashes on this line in InitInstance, which checks if there is a recently used file to load:
if (m_pRecentFileList->m_nSize > 0 && !m_pRecentFileList->m_arrNames[0].IsEmpty())
I have gone through the code in InitInstance line by line and I don't see any problems. Every global variable is initialized. Return codes are checked for every function call. I changed all my strcpy's to strncpy to make sure there aren't any overflows. Weirder yet, when I compile the program - exact same code, line-for-line - in VC++ 6 rather than Visual Studio 2008 - he doesn't get the crash. SAME CODE!! The only difference is that with Visual Studio 2008 I link MFC in statically because I'm running Windows 7 (64-bit) and he doesn't have the DLLs on XP. I installed XP SP3 on a computer and did not get the crash. Two other testers have XP SP3 and do not experience the crash. I asked him to use msconfig to disable Startup programs. He did, and it still crashed. I asked him to use msconfig to reboot into diagnostic mode. He did, and it still crashed. Doesn't that suggest it's my code and not a conflict with something on his system? But if it's such a bad bug, then why doesn't even one other person see it? I don't know what to do at this point. I can't find it if I can't reproduce it. And not only can I not reproduce it, no one else who has run the beta can reproduce it. I'm tempted to ignore the problem on his system and move on, but what if I release the program and it starts crashing on 10% of systems? How do I find this bug??? Any help would be greatly - hugely - appreciated. I've been working on this for a week, and I'm out of ideas.
When I'm having issues that I cannot reproduce, then I use remote desktop/remote assistance to take control of the customer computer and install Windows Debug Tools (WinDbg). WinDbg allows you to debug applications: 1) To see call stack while debugging then you need to upload Program Database files (PDB) generated with the EXE/DLL files. 2) To see source code then you need to upload the source used to compile the application. 3) To see values of variables (and not just addresses), then you need to compile the application without optimization turned on. P.S. I would add the following to the problem line you have shown: # Check that m_pRecentFileList != NULL # Change m_arrNames to a proper container and check the size of that instead of using m_nSize
-
When I'm having issues that I cannot reproduce, then I use remote desktop/remote assistance to take control of the customer computer and install Windows Debug Tools (WinDbg). WinDbg allows you to debug applications: 1) To see call stack while debugging then you need to upload Program Database files (PDB) generated with the EXE/DLL files. 2) To see source code then you need to upload the source used to compile the application. 3) To see values of variables (and not just addresses), then you need to compile the application without optimization turned on. P.S. I would add the following to the problem line you have shown: # Check that m_pRecentFileList != NULL # Change m_arrNames to a proper container and check the size of that instead of using m_nSize
Yes, yes, and yes - thanks. I can see this is the direction I need to go. I have WinDbg installed, but my knowledge of how to use it is minimal. I've used it to view crash dumps, but never for remote debugging and I don't know how that works. I need to google remote debugging for more detailed instructions.
Snakefoot wrote:
I would add the following to the problem line you have shown: # Check that m_pRecentFileList != NULL # Change m_arrNames to a proper container and check the size of that instead of using m_nSize
Yeah, it's becoming clear to me that I need to check this pointer before trying to use it. The reason I didn't is that I didn't think there was any way it could be invalid after I'd made the call to
LoadStdProfileSettings(4);. Could you tell me under what circumstances this structure might not be populated properly after this call? There's no return value to check with LoadStdProfileSettings. I don't know what you mean by "change m_arrNames to a proper container". What is a "proper container". Confession: I learned to program in the pre-Windows DOS world (I am old) and I'm more adept with procedural programming than object-oriented programming. -
Yes, yes, and yes - thanks. I can see this is the direction I need to go. I have WinDbg installed, but my knowledge of how to use it is minimal. I've used it to view crash dumps, but never for remote debugging and I don't know how that works. I need to google remote debugging for more detailed instructions.
Snakefoot wrote:
I would add the following to the problem line you have shown: # Check that m_pRecentFileList != NULL # Change m_arrNames to a proper container and check the size of that instead of using m_nSize
Yeah, it's becoming clear to me that I need to check this pointer before trying to use it. The reason I didn't is that I didn't think there was any way it could be invalid after I'd made the call to
LoadStdProfileSettings(4);. Could you tell me under what circumstances this structure might not be populated properly after this call? There's no return value to check with LoadStdProfileSettings. I don't know what you mean by "change m_arrNames to a proper container". What is a "proper container". Confession: I learned to program in the pre-Windows DOS world (I am old) and I'm more adept with procedural programming than object-oriented programming.A proper container is one that keeps track of its allocation like std::vector or MFC::CSimpleArray. But I see that you are using CRecentFileList(), and it seems to be without such features.
-
A proper container is one that keeps track of its allocation like std::vector or MFC::CSimpleArray. But I see that you are using CRecentFileList(), and it seems to be without such features.
I made a small change to the program, and now it's crashing on my own development system - which is sort of bad, but also sort of good. The problem is not the line I quoted. It's crashing when it tries to run the app. I think I must have a buffer overrun somewhere, though I have no idea where. I looked at Bounds Checker but it costs $1500. Is there a cheaper alternative? Geez - I am losing it, or I need more sleep or something. I deleted something crucial, that is all. Back to the original problem...
modified on Wednesday, March 17, 2010 6:02 PM
-
A proper container is one that keeps track of its allocation like std::vector or MFC::CSimpleArray. But I see that you are using CRecentFileList(), and it seems to be without such features.
Snakefoot wrote:
A proper container is one that keeps track of its allocation like std::vector or MFC::CSimpleArray. But I see that you are using CRecentFileList(), and it seems to be without such features.
I put in a check that the list exists, and for some reason I cannot fathom, it is not created properly on this one guy's system, though it works fine for everyone else. I can't imagine what he can be doing on his computer that would prevent this standard MFC call from working properly. Does anyone know? I'd rather not do it all manually if I don't have to. I'd rather detect systems that don't support it, but I don't know of any reason why a system would not support it. Can anyone make a guess on this?
-
Snakefoot wrote:
A proper container is one that keeps track of its allocation like std::vector or MFC::CSimpleArray. But I see that you are using CRecentFileList(), and it seems to be without such features.
I put in a check that the list exists, and for some reason I cannot fathom, it is not created properly on this one guy's system, though it works fine for everyone else. I can't imagine what he can be doing on his computer that would prevent this standard MFC call from working properly. Does anyone know? I'd rather not do it all manually if I don't have to. I'd rather detect systems that don't support it, but I don't know of any reason why a system would not support it. Can anyone make a guess on this?
I fixed the problem. I still have no idea why the standard call wasn't working on his system. But I changed this:
LoadStdProfileSettings(4);to
CString strSection = "Recent File List"; CString strEntryFormat = "File%d"; m\_pRecentFileList = new CRecentFileList(1, strSection, strEntryFormat, 4); m\_pRecentFileList->ReadList();And voila! No crashes - it's working fine. I can't believe I spent a week and a half of my life on this. On the plus side, my startup code is vastly cleaner after 10 days of intense scrutiny.