My application uses VC++ 2003. While executing in the Unicode release mode it crashes at
CMDIFrameWnd* pFrame = new CMainFrame;
in InitInstance() of startup project. The error message shows that the application crashes at mfc71u.dll
Click the link to see the error message
The same application runs well on other systems.
Please suggest me what could be the reason for the crash.
Thanks
Shyam
It would help if you posted more information such as:
A stack trace to the fault.
The source code around the crash.
The exception generated.
This is the bare minimum information you should automatically include with any crash.
Related
When running a UWP project I'm working on I receive the following dialog.
"Unable to activate Windows Store app 'MyAppsMangledName'. The 'MyExeName' process started, but the activation request failed with error 'The App didn't start'."
The Visual Studio output has the following.
The thread 0x3d4c has exited with code -1073741515 (0xc0000135).
The thread 0x3b50 has exited with code -1073741515 (0xc0000135).
The program 'MyExeName' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
The Event Viewer has 3 events that basically restate the popup dialog in 3 different ways and nothing else.
Running Process Monitor during the startup shows me many dlls being successfully loaded but nothing indicating failure besides some NAMENOTFOUND events which unfortunately don't show what name wasn't found.
In Win32 a helpful dialog usually indicates which dll could not be loaded. And of course with .Net apps the fusion logs make tracing this very straight forward. But for Store/UWP apps I can't seem to find a good way to track down the offending dependency.
This just hit me too on a project I'm working on. And after much digging, someone on my team was able to figure it out. So figured I'd share it for others struggling with the same issue.
We're doing UWP with C++ using VS2015. So with that in mind, there is a program called gflags located for me at C:\program Files (x86)\Windows Kits 10\Debuggers\x64\gflags.exe
So you'll want a cmd window with admin, and run the command gflags.exe -i your-program-name.exe +sls
Note: gflags wasn't in my path so either add the path or navigate to where it is before executing the command.
Just pass in the name of the exe without directories. What it does is sets a registry setting for VS that turns on sls (show loader snaps) for exe's matching that name. Then run your application in VS and and you'll get a large amount of dll loading information including names of the dlls that fail to load in your output window. In our case it was this:
5038:34f4 # 789320468 - LdrpProcessWork - ERROR: Unable to load DLL: "vccorlib140d_app.DLL", Parent Module: "E:\projects---\Source\Builds\vs2015_Debug_UWP_x64\AppX---.exe", Status: 0xc0000135
Another quicker alternative way to test this (YMMV) was to compare the output with another build config that does work. In our case, we can run release builds just fine, but debug builds barf. And the release output showed vccorlib140_app.dll loaded while the debug had it missing.
I've been searching for a while and finding many old articles but also found one with a Regedit to enable the dumping of .dmp files, which isn't doing it.
Instructions I used are from Microsoft, Collecting User-Mode Dumps (MSDN)
According to Symantec no re-boot is required.
I created it for both:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\Windows Error Reporting\LocalDumps and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.
All I get is a report.wer file. No dump. The event log is writing exceptions about every minute and about every 30 minutes the app pool dies, so I'm trying to get the details on where the problem is coming from.
Anyone know why those keys aren't working? Does the report.wer provide anything useful for me? One StackOverflow post said SOS extension and when I search for it Microsoft points me to download WinDbg which I already installed. A lot of instructions I find from 2008 and older seem out-dated.
Edit: I managed to get dump files by running the debugging tool on the server. But there's so much wrong information out there on how to get the actual code info that none of it is working.
I've tried adding the symbols path to my pdb files and I've tried
.loadby sos clr
.loadby sos
!CLRStack
!analyze -v
and all I get is wrong symbols.
WER won't catch crash dumps if there is no crash at all. You know that a process can exit normally, when you think it crashes.
If you do want to learn why a process exits (normally or abnormally), the most reliable way I can think of is to utilize Debug Diag (which is built specifically for IIS),
http://msdn.microsoft.com/en-us/library/ff420662.aspx
Note that you probably should use Debug Diag 2.0 at this moment, and must add Kernel32!ExitProcess and Kernel32!TerminateProcess as breakpoints.
We are running Windows Server 2003 R2 with SP2. When I login I get the following messagebox twice
"Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
Below are the steps I have tried and still get the error when I login
Disabled all Non-Microsoft Service and reboot the server
Disabled all startup items from msconfig and reboot the server
Repaired .Net Framework 3.5 SP1
There are no event in either Application of System log indicating the cause of the error message
My question is how do I stop these error messages and find out which application is throwing them. Are there utilities out there to diagnose the problem.
Thanks for your help and helping a newbie to the IT Field
Juzer
When you get the messagebox on the screen, if you bring up task manager, and then select go to process, you should be able to see the process responsible for the display of the messagebox. That is to say from the "Applications" tab select the messagebox in task manager and then select go to process
I am facing some critical issue which might be interesting for whom , those who are playing with window azure sdk. I have created on EXE which read performance counter data like CPU, memory, asp.net session from system like
queryCollection = ExecuteWMIQuery("SELECT * FROM win32_perfformatteddata_perfdisk_physicaldisk");
and I have aded this EXE in startup task of simple asp.net application which i have uploaded on window Azure. Now when i connecting to RDP of that I can see following errors in my event log as per below.
Disabled performance counter data collection from the
"ASP.NET_64_2.0.50727" service because the performance counter library
for that service has generated one or more errors. The errors that
forced this action have been written to the application event log.
Correct the errors before enabling the performance counters for this
service.
======================================================================
Windows cannot open the 64-bit extensible counter DLL
ASP.NET_64_2.0.50727 in a 32-bit environment. Contact the file vendor
to obtain a 32-bit version. Alternatively if you are running a 64-bit
native environment, you can open the 64-bit extensible counter DLL by
using the 64-bit version of Performance Monitor. To use this tool,
open the Windows folder, open the System32 folder, and then start
Perfmon.exe.
So i am thinking that my EXE trying to fetch performance counter for 32 bit (win32 indicate that) and that will log above error.
So anyone here came across this type of issue , also if my guess is correct then is there any way to implement my EXE logic such way that it can be run smoothly in any environment(32 or 64 bit)?
Hope that this would remain interesting question here!!!
Thanks In Advance
Arun.
That is correct. IIS running in Azure is running 64-bit unless you change it to run 32-bit in a startup task. You could try building it with the Any CPU setting. But most likely the best way is to do something like what the sysinternal tools does. They will spawn a new process that runs in 64-bit mode when needed. Then you can handle both.
I encountered this error while migrating to a Azure VM.
Solved it by using the InstallUtil which is located in the Framework64 folder instead of the one in the Framework folder
I've just updated to MT 4.0.1 from 3.2.6. Now it seems that exception reports no longer contain stack traces when running on the device.
I have an exception handler attached to AppDomain.CurrentDomain.UnhandledException that I use to save an exception report to a file. On the simulator in both Debug & Release modes, UnhandledExceptionEventArgs.ExceptionObject.StackTrace is set. On the device in both Debug & Release modes that property is null.
I have tried checking "Emit debugging information" in the "Compiler" section of the project options. I have tried adding "--nosymbolstrip" to the MT build args. I have tried LLVM both enabled and disabled.
Any ideas? We will not be able to update in the App Store until we're confident that any exception reports we receive contain the necessary diagnostic info.
What information does ExceptionObject.ToString() provide? It should include the error message and stack trace. I know this has been working for me, b/c I recently used it to submit a bug to Novell.
Also, you might want to wrap a try-catch around your app startup in static void Main(), as AppDomain.UnhandledException is meant to be used for off-thread exceptions.
This would seem to be fixed in MonoTouch 4.0.4.1, though I didn't see that mentioned in the update description. Perhaps someone from Xamarin can confirm it was fixed on purpose.
For the record, it was stack traces in general that were broken on device, not just those associated with an exception. Formerly if you did new StackTrace() then its frames would be incomplete.