I frequently have the following crash from cl.exe. This happens both when compiling and running other a help command on cl. This is happening on Windows Server 2008, but I think this happens sometimes on Windows XP also. This is occurring very frequently within Jenkins when when running waf configure.
I haven't been able to find anything online to fix this problem, although there are mentions of kernelbase.dll crashing in other programs.
Does anyone have any thoughts on how to avoid this problem?
Thanks
Log Name: Application
Source: Application Error
Date: 1/24/2012 4:25:51 PM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer:
Description:
Faulting application name: cl.exe, version: 15.0.30729.1, time stamp: 0x488ef6ea
Faulting module name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdbdf
Exception code: 0x0eedfade
Fault offset: 0x0000b727
Faulting process id: 0xd74
Faulting application start time: 0x01ccdae720a1cbbd
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: 5e9f206e-46da-11e1-a28d-bc305bd1c68c
Event Xml:
1000
2
100
0x80000000000000
55240
Application
cl.exe
15.0.30729.1
488ef6ea
KERNELBASE.dll
6.1.7600.16385
4a5bdbdf
0eedfade
0000b727
d74
01ccdae720a1cbbd
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe
C:\Windows\syswow64\KERNELBASE.dll
5e9f206e-46da-11e1-a28d-bc305bd1c68c
Check:
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/05764562-0133-4e6d-a613-bfe1ec2f0c1d/.
This seems to be an issue with updated dlls. I would also suggest compiling your program outside of Jenkins just to be sure that it is not an issue with Jenkins (either paths, or anything else).
Related
When trying to run my executable program on a Windows Server 2008 R2 (x64), it fails immediately and Windows says "Program (x64) has stopped working".
The same executable works on many other machines.
Even on other machines with the same OS.
The program comes with its own Dlls in the folder.
Even if it would require other Dlls that arent present i think the system would say so?
Here is the output from Windows Event Viewer:
Faulting application name: dscp.exe, version: 19.0.0.398, time stamp: 0x5d8b42ef
Faulting module name: VERSION.dll_unloaded, version: 0.0.0.0, time stamp: 0x4a5be082
Exception code: 0xc0000005
Fault offset: 0x000007fefbcc15b4
Faulting process id: 0x1db4
Faulting application start time: 0x01d5744a0d493693
Faulting application path: C:\TEMP\DebugW\dscp.exe
Faulting module path: VERSION.dll
Report Id: 50adb64b-e03d-11e9-a7b2-000c29b302dd
I have looked up VERSION.dll and it seems to be a Windows system Dll.
I dont' know how to debug this issue.
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.
Morning,
I don't know if anyone else has experienced the following.
Up until this morning my Windows 7/Visual Studio 2010 Ultimate/StyleCop 4.7.11.0 setup was working fine.
However when I booted my PC this morning, started Visual Studio 2010 and loaded a solution with stylecop enabled on various projects I found the IDE crashed when I tried to build any styelcop enabled projects. e.g. thjose with the following entries in .csproj
...
false
Removing these StyleCop entries from the .csproj files or uninstalling StyleCop "fixes" the problem on their own and allows me the build the solution. But re-instating the stlecop entries in the .csproj files and re-installing StyleCop v4.7.11.0 or v4.7.17.0 caused the problem to re-occur.
The only errors in the Event View referred to NTDLL.DLL
Faulting application name: devenv.exe, version: 10.0.40219.1, time stamp: 0x4d5f2a73
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f
Exception code: 0xc00000fd
Fault offset: 0x0002e17c
Faulting process id: 0x17d8
Faulting application start time: 0x01cd0cd0f8cd1730
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 56b93280-78c4-11e1-bef3-001cc0c2a2ac
or once CLR.dll
Faulting application name: devenv.exe, version: 10.0.40219.1, time stamp: 0x4d5f2a73
Faulting module name: clr.dll, version: 4.0.30319.239, time stamp: 0x4e181a6d
Exception code: 0xc00000fd
Fault offset: 0x00038b13
Faulting process id: 0x14c8
Faulting application start time: 0x01cd0cbf6cf79511
Faulting application path: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: c82f5abd-78b2-11e1-b990-001cc0c2a2ac
I think I have answered my own question...
The change I did make but discounted was that I used the StyleCop Settings contextr menu option in Visual Studio to set settings file's to be merged with a parent settings file, e.g.:
Solution
Settings.StyleCop
Project1
Settings.StyleCop (merge with Solution\Settings.StyleCop)
the contents of the files were as follows:
Solution\Settings.StyleCop
<StyleCopSettings Version="105">
<GlobalSettings>
<StringProperty Name="LinkedSettingsFile">Settings.StyleCop</StringProperty>
<StringProperty Name="MergeSettingsFiles">Linked</StringProperty>
</GlobalSettings>
</StyleCopSettings>
Project\Settings.StyleCop
<StyleCopSettings Version="105">
<GlobalSettings>
<StringProperty Name="LinkedSettingsFile">..\Settings.StyleCop</StringProperty>
<StringProperty Name="MergeSettingsFiles">Linked</StringProperty>
</GlobalSettings>
</StyleCopSettings>
Deleting these Settings files solved the problem. Although I don't understand why. Could it be some form of circular reference in the merge/link settings?
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.