Simply, I cannot run App verifier (WOW or 64-bit). It simply does not start. Event viewer says:
Faulting application name: appverif.exe, version: 10.0.18362.1, time stamp: 0x58ca3409
Faulting module name: ntdll.dll, version: 10.0.18362.1139, time stamp: 0x335bbdaf
Exception code: 0xc0000374
Fault offset: 0x000dfa1d
Faulting process ID: 0x2ad0
Faulting application start time: 0x01d6aa7ad4a12bf6
Faulting application path: C:\Windows\SysWOW64\appverif.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: 235c3a4d-2d54-4436-99bf-b54a217c9a7f
Additionally, I tried to run appverif.exe (in system and syswow64) under Visual Studio and I see:
EDIT (Update based on comments)
Some are suggesting that Application Verifier does not have a GUI. However, last time I ran it, I saw the following:
I asked Microsoft employee Gov Maharaj (from application compatibility team) and they already know about the issue and the issue is fixed in an update for the Windows 10 2004 SDK which was released in December 2020 (19041.685.201201-2105.vb_release_svc_prod1_WindowsSDK.iso):
The Windows 10 SDK, Version 2004 SDK servicing update (released
12/16/2020) contains the following fixes. If you encounter these
issues, we recommend that you update your version of the SDK as soon
as possible to avoid them:
Resolved issue that prevented AppVerifier from working
Download and install the update to fix it.
I managed to run the verifier under a SYSTEM account using PsExec:
...PsTools\PsExec64.exe -i -s C:\Windows\System32\appverif.exe
I've tried the recommended methods - installing the latest windows SDK and running the program through 'PsExec64.exe -i -s' but neither worked. This program seems to be something Microsoft periodically breaks, judging by what I've read.
I ran appverif.exe through visual studio and saw the following call stack on crash:
ntdll.dll!RtlReportCriticalFailure() Unknown
ntdll.dll!RtlpHeapHandleError() Unknown
ntdll.dll!RtlpHpHeapHandleError() Unknown
ntdll.dll!RtlpLogHeapFailure() Unknown
ntdll.dll!RtlpFreeHeapInternal() Unknown
ntdll.dll!RtlFreeHeap() Unknown
msvcrt.dll!00007ffd44449c9c() Unknown
appverifUI.dll!00007ffc9a41f9d6() Unknown
appverifUI.dll!00007ffc9a411636() Unknown
appverif.exe!00007ff64965281b() Unknown
appverif.exe!00007ff6496615ed() Unknown
kernel32.dll!00007ffd43957034() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
It seems to be crashing after a heap free.
Related
I am using VS2015 and trying to validate connection after importing publish profile generated by winhost, when I click on Validate connection VS2015 crashes.
I have tried cleaning up and rebuilding but hat didn't help, I have also restarted machine without any luck.
I have also enabled logging by running devenv /Log but can't make any sense out of ActivityLog.xml what went wrong exactly, I have uploaded it here
What went wrong with Visual Studio 2015 and how could I fix it?
UPDATE: I also tried resetting settings devenv /resetsettings but that didn't help.
EventLog shows following Error:
Faulting application name: devenv.exe, version: 14.0.24720.0, time stamp: 0x564ea97e
Faulting module name: clr.dll, version: 4.6.1063.1, time stamp: 0x5653653c
Exception code: 0xc0000005
Fault offset: 0x0007482d
Faulting process ID: 0x13f0
Faulting application start time: 0x01d17609c3c2b002
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report ID: 2fab7a5b-6003-417f-adb3-8f45ec987a72
Faulting package full name:
Faulting package-relative application ID:
Update2:
As per #magicandre1981 request. I ran procdump -ma -i C:\dumps from command line before doing anything else. Then ran VS2015, went to publish and clicked on Test connection when VS crashed, there was a .dmp file in C:\dumps. Here's zipped dump file
ok, the PDB is now online and I was able to look at the dzmp with Windbg. The crash (NULL_POINTER_READ_INVALID_POINTER_READ) happens at clr!MethodTableBuilder::CreateMethodChainHash+0x8a.
I have no idea how to fix it. Submit the issue to Microsoft via connect so that Microsoft can fix it with the Update 3.
Generally "Source Control Explorer" and "Team Explorer" windows can be opened but sometimes this windows cause crash independently. If it doesn't I try to get latest version but it crashes after downloading some files.
Non-controlled solutions work fine but if I can try to open a controlled solution VS crashes on loading solution.
This problem started today. I use Windows 10 but migrated from Windows 8.1 a couple of months ago. In this morning windows session could not start when I've entered my password to windows login screen. So I've resetted my computer by clicking reset button. But Windows 10 re-run its migration tool and I think that it repaired some applications. I checked the Programs and Features out then a lot of apps seems installed today.
Repaired my VS install from Programs and Features but it didn't solve. Tried WinThruster, it found issues over 1000 but it didn't solved, too.
VS adds these three logs together to event viewer when app crashes.
Error:
Fault bucket 128975310163, type 5
Event Name: CLR20r3
Response: Not available
Cab Id: 0
Problem signature:
P1: devenv.exe
P2: 12.0.40629.0
P3: 5590c8a4
P4: mscorlib
P5: 4.6.1038.0
P6: 5615c1ac
P7: 3b10
P8: 7
P9: System.InvalidProgramException
P10:
Attached files:
C:\Users\Onur\AppData\Local\Temp\WERF382.tmp.WERInternalMetadata.xml
C:\Windows\Temp\WERFF3A.tmp.csv
C:\Users\Onur\AppData\Local\Temp\WERFF3B.tmp.appcompat.txt
C:\Users\Onur\AppData\Local\Temp\WERA2A.tmp.WERDataCollectionFailure.txt
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_devenv.exe_d949c0dbc7d16a4f9e0b0cdb431782229fc6a1_5b0449f2_1c961310
Analysis symbol:
Rechecking for solution: 0
Report Id: 1b1069cb-61a5-4133-881d-e3ae5b11ae68
Report Status: 4105
Karma demeti (*): 944bc6d8e7edc70b70df076898124c29
(*) I translated from turkish but couldn't find the english equivalent of "Karma demeti" after googling. Maybe it can be "Mixed bucket".
Error:
Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidProgramException
Stack:
at Microsoft.TeamFoundation.VersionControl.Client.QueuedActionLimiter.DeliverAction(System.Object)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
Info:
Faulting application name: devenv.exe, version: 12.0.40629.0, time stamp: 0x5590c8a4
Faulting module name: KERNELBASE.dll, version: 10.0.10586.0, time stamp: 0x5632da1c
Exception code: 0xe0434352
Fault offset: 0x000bd8a8
Faulting process id: 0x1ae4
Faulting application start time: 0x01d13672bb0a871a
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe
Faulting module path: C:\WINDOWS\SYSTEM32\KERNELBASE.dll
Thanks in advance.
First, make sure you have upgraded both your TFS and VS to the latest edition of its version.
Then check whether you can reproduce this issue on another client machine, if the issue only occurs on your client machine, you can try resetting VS settings and add-in settings (devenv /ResetSettings) and (devenv /ResetSkipPkgs), try rebuilding all templates (devenv /setup).
If you already use the lasted Update, Update 5, you should report this crash on connect. You should also provide a crash dump. To do this you can configure Windows Error Reporting to generate dumps or install Procdump as post Mortem Debugger by running procdump -ma -i C:\dumps. Now repo your crash and if you got a dump, zip the dmp and attach it to the report.
I'm trying to sign my setup package from within InstallShield 2012LE in Visual Studio 2012. I have an MS Authenticode Cert from Symantec (VeriSign). There are two issues I'm seeing.
Firstly if I select Sign Output Files -> Setup.exe and Windows Installer Package (Or just windows installer package) visual studio crashes. Event Log shows two errors
Faulting application name: devenv.exe, version: 11.0.50727.1, time stamp: 0x5011ecaa
Faulting module name: WINTRUST.dll, version: 6.2.9200.16420, time stamp: 0x505a9691
Exception code: 0xc0000005
Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 758017E4
Stack:
Also if I set "Use Software Identification Tag" to yes then I get the following error when trying to build the installer package.
Error 108 -1027: Failed signing TagCreatorID_EE17CD21-FE17-4342-8CA5-E0B993AAEB3E.swidtag
ISEXP : error : -1027: Failed signing TagCreatorID_EE17CD21-FE17-4342-8CA5-E0B993AAEB3E.swidtag
Has anyone come across these issues before and know of a workaround? It works fine is I turn off Software Identification Tag and only sign Setup.exe but I also require the options above. The certificate also signs all my DLLs and EXEs without issue.
I have a 32-bit windows .exe. Which will run as windows service. This .exe runs fine as servics for window 2000/xp 32-bit version.
However when try to run on 64-bit windows 2008 server it crash. I am observing two cases.
1) If I build the application on VC++ 6. From Event log entry it seems to Kernel.dll is crashing.
Faulting application name: , version: , time stamp: 0x4e6461c0
Faulting module name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdbdf
Exception code: 0xe06d7363
Fault offset: 0x0000b727
Faulting process id: 0xe2c
Faulting application start time: 0x01cc83cb1052e4b3
Faulting application path: C:\Program Files (x86)\\\Admin.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: 4e0693b4-efbe-11e0-a07f-001143e8bb9d
2) If I build the application with VS2005 32 bit, A run time error displayed and Event log says msvscrt.dll is crashed.
Faulting application name: , version: ,
Faulting module name: MSVCR80.dll, version: 8.0.50727.4927, time stamp: 0x4a2752ff
Exception code: 0x40000015
Fault offset: 0x000046b4
Faulting process id: 0x34c
Faulting application start time: 0x01cc8c4f2a223426
Faulting application path: C:\Program Files (x86)\\\Admin.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5\MSVCR80.dll
Report Id: 69554d57-f842-11e0-a07f-001143e8bb9d
Please help me out resolve this issue.
You need to diagnose the problem better before you can solve it, which probably means finding a way to reproduce it while program is executing under the debugger. Some suggestions:
Since your service is EXE (and not DLL that runs under svchost.exe, which is a generic host process name for services that run from DLLs), you should be able to use "Attach to Process" option in Visual Studio to attach the debugger to it. You might need to start the Visual Studio as administrator and/or change the user under which the service executes to be able to do that.
Also, if the service crashes soon after starting, you might need to call MessageBox with MB_SERVICE_NOTIFICATION to pause execution long enough so you can attach the debugger.
However, if the service crashes during startup before it even reaches the MessageBox, you need to
build it as console application. Now you can actually start it under the debugger and see what is going on.
Can you please try installing redistributable package on client machine to run your application.
I've got an application we use at our company.
All of our Windows XP PCs and Windows 7 PCs use it.
I can run it in the debugger under Visual Studio 2008 and build the Installer that all of the other PCs use to install it with, but I can not get it to run after installing on my PC (the installation shows no errors).
Under Event Viewer > Windows Logs > Application, two (2) events are fired:
The Error thrown when I try to run the installed application:
Faulting application name: Suite.exe, version: 2.2.21.0, time stamp: 0x4d389f32
Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b802
Exception code: 0xc00000fd
Fault offset: 0x00000000000076cf
Faulting process id: 0x1424
Faulting application start time: 0x01cbb8f485a2a9d8
Faulting application path: C:\Program Files\Aaon Coil Products, Inc\ACP Software Suite\Suite.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: c58bd590-24e7-11e0-b398-00248103a942
An Informational message fires up immediately after with Windows Error Reporting:
Fault bucket 28268826, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: Suite.exe
P2: 2.2.21.0
P3: 4d389f32
P4: ntdll.dll
P5: 6.1.7600.16559
P6: 4ba9b802
P7: c00000fd
P8: 00000000000076cf
P9:
P10:
Attached files:
C:\Users\cp-jpool\AppData\Local\Temp\WER492A.tmp.WERInternalMetadata.xml
These files may be available here:
C:\Users\cp-jpool\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_Suite.exe_e131a0d577e0788f7db9b54fd53b35e27d8860e2_11df4dea
Analysis symbol:
Rechecking for solution: 0
Report Id: c58bd590-24e7-11e0-b398-00248103a942
Report Status: 0
This repeats every time I try to run the application I made with this PC ...on this PC, but no where else.
Could someone give me some idea of what's going on and how to fix it?
Do you get prompted to elevate Visual Studio when you run it?
If so, try running the app elevated.
Basically, isolate what's different between the two:
Can you run it in Visual Studio without debugging? Including when you set it to "Release"?
How about if you build and install it as "Debug" then start it and try to attach to it as it crashes? (You can set the JIT debugger via the registry here: http://msdn.microsoft.com/en-us/library/5hs4b7a6.aspx)
Good luck!
It turned out that my application uses a control that does not run on 64-bit environments.
Apparently, the debugger in VS2008 will not throw an error whenever one of these old style DLLs fails.