In a process to migrated an existing 32 bit MFC Code to 64 bit, I did a successful build and tried to test the code
Unfortunately while testing the process seems to fail (rather crash) in
Failing Stack
hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate, pParentWnd->GetSafeHwnd(), AfxDlgProc);
CreateDlgIndirect(lpDialogTemplate, CWnd::FromHandle(hWndParent), hInst)
CDialog::DoModal()
No Dump is generated nor the generated exception is getting caught by SEH
I tried comparing the debug run with an existing working Win32 debug run but could not find any significant differences
At this moment I am clueless how I should proceed. Any sort of help is highly anticipated
Exception Info:
First-chance exception at 0x000007fefd89a5ed (KernelBase.dll) in xyz.exe: 0x00001234: 0x1234.
Actual Problem
The Actual Problem was due to pointer truncation that was happening causing it to crash. #OwenWengered's solution did help me to pinpoint the issue and to deal with all such pointer truncation which I am currently working. Which me luck :-)
Just as HansPassant already said in the comments, there's little you can do other than debugging it and tracing what actually the application tried to do at that time.
For complete start, the "0x1234" value seems very odd. If you have sources, find the offending line and set breakpoint there. Then, once hit, check which of the values (hinst? lpdialogtemplate? pParentWnd?) might have been trimmed to that 0x1234. It is possible that in your debug session the value 1234 will be different, so be careful and check any pointers that look odd, ie. are too small or seem unaligned.
If you have sources, post the relevant parts around (before!) that call you quoted.
If you don't have any sources, try to get them :)
If you can't get them, then you can debug in raw (dis)assembly, but then, you'd need to quote not only the asm parts, but also register and stack values.. and well, it will be hard to get audience probabaly.
It's hard to say anything more, as currently I/we know even less about your case than you :)
I just had a very similar issue. Along time ago when coding in VS6 you were able to create a manifest file (under resources) to change the look of your dialogs to give them an WinXP dialog look (with rounded edges).
https://msdn.microsoft.com/en-us/library/aa289524%28v=vs.71%29.aspx
So I had a file called IDR_WIN_XP_THEME under RT_MANIFEST in Resources.
I was able to upgrade to all versions of Visual Studio. But when I converted the app to 64 bits in VS2015 and tried to open the application in 64 bits it failed with an exception error.
Exception thrown at 0x000007FEFC94965D (KernelBase.dll)
I just deleted the IDR_WIN_XP_THEME manifest file and it started working.
Related
please can anybody help me? I'm suffering - every time I debug my c++ (opencv) code, I have an exception and then the following msg:
No symbols are loaded for any call stack frame. The source code cannot be displayed.
What's the matter, and how can I solve it? my colleagues have executed the same code but had no errors or exceptions.
I am running Windows 7 32 bit and Visual Studio 2005, opencv 2.2.0
Although the OP's issue has been solved, there is another possibility for this error that I have come across (might help someone else).
You can check under Debug->Exceptions; if any of the exceptions in this window are checked, it may show that popup if you come across a First Chance Exception. None of these need to be checked to simply debug your code, but are helpful if you're trying to track down a particular exception.
My problem has been solved... It was a problem with an image path.
We have a problem for which I am looking for a direction. We have an old MFC based application, and due to various reasons, the application is crashing sometimes intermittently in some weird scenarios. And even the customers who are using our application and getting these crashes are finding difficulty in identifying the pattern of crash. So, I had a thought that, if we can have a mechanism by which we can generate a log whenever the application crashes. Like for example, the call stack or any other information in that log. I know,, we can use the crash dump in this case, but then I feel like having a log is a better option. So any help or information in this regard would be really helpful.
Thank you.
You can find a good implementation of crash reporter in the link here.
When you compile your release build, make sure that both DEBUG and /MAP are enabled. Store your binaries together with your .map files and let your customer run this version until a crash is produced. In the Event Viewer you will then find a crash log with a crash offset. Then debug step into your code (F10) and use the crash offset together with some nifty tricks and tricks to jump (set the EIP register to... well, you have to google this a bit) to the location where the crash occurred. You should now be able to find the error!
I'm working on the development of a software in C++ on Visual Studio 2010. As this software should be run on servers where human interaction is not available, I really really need to get rid of this "program.exe has stopped working" window that pops up in the release version in case of errors. I just want the program to terminate (maybe also give an error message, but not necessarily) and not have it remain blocked waiting for someone to click the "Close the program" button. I have to mention that I have 64 bit Windows 7 Professional on my machine.
I have read about several things, such as:
the _set_abort_behavior function. This solves the case when abort() is called, but that is not the case for errors like "vector subscript out of range".
I know I could be solving some of these errors by doing exception handling, but not all errors are exceptions, therefore this would not solve my entire problem.
I've also read something about the Dr. Watson debugger, which is supposed to terminate the application silently, but I have the impression that this debugger is not available for Windows 7. Plus I don't know if this debugger would solve my problem in the release mode...
I don't find that disabling Error Reporting on my entire machine is an elegant option, although I read that this could also be an alternative (not really one that I want to take).
How can I do this in Visual Studio? Are there any settings I could use?
Is there maybe a way to turn all errors in exceptions in Visual Studio, so that I can solve the problem with the exception handling mechanism? (please be tolerant if this was a stupid question)
I'm looking forward to your proposals. Many thanks for your time!
Best regards,
Cornelia
You can use
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
MSDN documentation for SetErrorMode
You can also refer here
Hope this will solve your problem...
A good way is to add your own unhandled exception filter (see SetUnhandledExceptionFilter() docs) and then write a log and a mini dump so that you can do whatever error handling you need to (eg close devices/handles) and you also have a crash dump that you can analyse later. Useful information in this answer: https://stackoverflow.com/a/1547251/188414
Sometimes this error occurs only because you have not added a & sign before the value you have used in scanf
Try the following which solved my problem
From
scanf("%d",code);
To
scanf("%d",&code);
I am working on this problem for two days and this is driving me mad as I am still quite new to C++. This violation access problem may be quite easy to you and may be answered thousands of times. But my lack of C++ knowledge make me even unable to identify the same problem ever answered.
OK here is my problem:
1. The major code is in a DLL. I am using Visual Studio 2008
2. This DLL called 3 external libraries: boost, tinyXML and SRILM (a NLP toolkit).
3. The error says: Unhandled exception at 0x5f4f068f (TextNormalizerAPI.dll) in tester.exe: 0xC0000005: Access violation reading location 0x00000000. , occurred only in Debug mode. And the error line was caused by an initialization of a boost::regex object (patUsername = regex("^\\W*#[A-Za-z]");) in my code, but the actual position was deeply inside the boost library, as shown in below figure:
**in most cases, I am not supposed to change the source code of Boost lib, isn't it? **
4. This error occurred only in Debug version, not in Release version.
5. I replace the whole solution with a old but fault-free version which worked properly in Debug mode. Yet immediately after I generating a Release version of this solution, error occurred in Debug mode!
UPDATE:
6. Thank you guys! I just tried something and found out that even a simple define a regex object in the first line of the entry of DLL will incurred this error! Any ideas?
7. yet initialize a regex object in the first line in the main() of the caller of this dll will not incur this problem.
Hope this description will help you recall something and give me some hint.
I want to ask:
what's the usual strategy to narrow down and spot the problem? thank you!
Looking at your code, you may want to verify that your m_position values are valid ... I'm seeing a escape_type_class_jump label in your code, so the goto or whatever mechanism you're using to jump to that label (I can't tell from the screen-shot) may be bypassing whatever checks are being done to verify that your position increments are still valid.
It looks to me like "this" (i.e., the basic_regex_parser) is NULL, and it's trying to call a method on a NULL object, which obviously doesn't work well. If "this" is indeed NULL (you can tell by looking in the "Locals" tab, then I would go up the call stack to the "basic_regex_implementation" level and see what's going on there -- where is this NULL value coming from? In general, looking at different levels of the call stack, and at the variables' values in those levels, will be helpful.
Alright, I presented this question on the MSDN forums but have yet to receive any kind of response so I figured I'd give StackOverflow a try.
I'm currently developing a DirectX application using VS2008 on Win7. I recently experienced a nasty memory corruption bug with a memory allocation class that grabbed byte aligned memory. During this bug I could still run the debug and release executables however it would crash due the instructions getting corrupted or whatever, but it would still execute for a bit until the crash.
I then stripped out the entire memory allocation class. The application runs perfectly in the IDE (release and debug builds) but I can't run any of the executables at all. They immediately crash with a non-responding/stop working error. And I don't think it is my environment because I get the same issue on another computer that wasn't having problems before either.
Dependency walker gives a "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." error and indicates that GPSVC.dll and IESHIMS.DLL can't be found. I've read that this can be misleading and just indicates a potential problem somewhere. And Dependency walker wasn't giving me this error the day before.
I haven't tinkered with any of the configuration or project settings or added new code. Any idea of what could be causing this behavior?
Also another note, I installed the Windows 7.1 sdk the same day. Think this could be some kind of compiler related bug?
Just in case some useful information pops up on the MSDN post, here is the link
http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019
Thanks!
Edit -
Here is the last couple lines of Dependency Walker's profiling output
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "EncodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF60 and returned 0x77B60FDB.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF70 and returned 0x77B59D65.
Second chance exception 0xC0000005 (Access Violation) occurred in "c:\users\joel\desktop\DXAPP.EXE" at address 0x0110152E.
Exited "c:\users\joel\desktop\DXAPP.EXE" (process 0x27D8) with code 255 (0xFF).
Is this referring to a DLL grabbing a null pointer or to my actual instructions? Going to read up on how to use WinDbg real quick and I'll post it's output if this doesn't shed any immediate light on the issue.
Edit 2 -
Simply running the application and hitting debug to bring up Visual Studio consistently brought me to where I'm compiling my shaders. I'm assuming at the moment that the root of the problem lies around this. However, I still don't understand the change of behavior during execution between using the IDE and not.
Solution! -
I was so thrown off by the previous memory corruption bug that I didn't realize my shaders weren't in a local directory to the executables. This in turn was generating a null pointer that wasn't handled properly after calling D3DX11CompileFromFile().
Shoot, sorry I meant to post this as a comment...
I can only suggest more diagnostic attempts.
One would be to profile the app from within Depends, this will also show dynamic DLL loads and might show something new. Also it captures the debug output. It may behave differently than launching in the debugger itself and provide a clue. You don't mention actually profiling so I thought I'd suggest it in case you hadn't. Also, pay very close attention to the paths for the DLL's loaded - you might be surprised at a DLL loading from a location other than you intended.
Another suggestion is to try at attach to the stopped app after the crash (before dismissing the error dialog). See if you can get a stack trace or anything out of it.
Finally try attaching (or even launching from) WindDbg rather than the IDE. Like the Depends profile, the difference in debugger behavior and how it hooks the app may allow the crash to happen, while providing the clues you need.
Good Luck!