On our continuous integration, we build a bunch on programs and libraries in serie, using one MSBuild process per product (about 50 products to build).
Often, we get a build failure on one of the product to build, but:
- it happens randombly on different products
- launching it again -> build success
- MSBuild fail before even starting compilation (in less than 1s)
We have these in the system logs:
Faulting application name: MSBuild.exe, version: 12.0.31101.0, time stamp: 0x545443d5
Faulting module name: MSBuild.exe, version: 12.0.31101.0, time stamp: 0x545443d5
Exception code: 0xc0000005
Fault offset: 0x0003cdbe
Faulting process id: 0x30b0
Faulting application start time: 0x01d0d07d89f8c3f8
Faulting application path: C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
Faulting module path: C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
Report Id: c7ae6b54-3c70-11e5-80d1-b82a72d611be
Faulting package full name:
Faulting package-relative application ID:
Return code is -1073741819
What could be causing this issue ?
Is there anything we can do beside launching the build N time to have it success ?
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'm a little stumped as to why this windows service is not running when using the Network Service account (but does so on other machines using the same code), getting me these two subsequent errors in event viewer:
Application: MyApplication.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 06F3C67E
Stack:
and
Faulting application name: MyApplication.exe, Version: 1.0.0.0, time stamp: 0x87654321
Faulting module name: ReferencedComLib.dll, Version: 1.0.0.0, time stamp: 0x12345678
Exception code: 0xc0000005
Fault offset: 0x0000c67e
Faulting process ID: 0x148c
Faulting application start time: 0x01d4df2e591220f2
Faulting application path: C:\Program Files (x86)\MyApplication\MyApplication.exe
Faulting module path: C:\Windows\SYSTEM32\ReferencedComLib.dll
Report ID: 9d8df956-4b21-11e9-80c8-00155dc82141
Faulting package full name:
Faulting package-relative application ID:
This seems to indicate that the service is looking for ReferencedComLib.dll under C:\Windows\SYSTEM32...
But ReferencedComLib.dll is actually located under C:\Windows\SysWOW64 - it's a COM-library from third party (and their installer correctly installs it into SysWOW64)
Running under Local System however this error does not even show up and the service runs without problems - and this problem is currently only reproducable on one stage, on all others it is running fine with Network Service.
How could changing the service account running the service result in a faulting module?
Simon Mourier was right, the problem was internal to the third party dlls I am using and it was trying to access a directory that was under C:\Users....
Reinstalling under a different path that Network Service could access fixed the problem.
I have an SSIS package that runs an executable by using Powershell. This worked fine for more than a year, but all of the sudden I get this strange error. I've isolated the command:
& '\\iguana01\VMMa\Process e-Invoice\ProcesseInvoice.exe' #('/countfiles','46')
If I run this command on my own PC there is no problem
But if I run this same command on the server (2012) then I get this strange error
This error dissapears when I run it on the 2012 server from a local folder
The event viewer doesn't give me that much more information, .NET Runtime 1026 error
Application: ProcesseInvoice.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.OutOfMemoryException
Stack:
at ProcesseInvoice.Program.Main(System.String[])
And an application error (1000)
Faulting application name: ProcesseInvoice.exe, version: 2.2.4.0, time stamp: 0x5857fbf7
Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e211319
Exception code: 0xe0434352
Fault offset: 0x0000b9bc
Faulting process id: 0x4488
Faulting application start time: 0x01d34be3a1f4ea5d
Faulting application path: \\iguana01\VMMa\Process e-Invoice\ProcesseInvoice.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: dfaca8c6-b7d6-11e7-b19f-005056b765a3
Don't know what the problem is and in which direction I have to look.
Pretty stupid, seemed that the processinvoicing*32.exe was still running under processes on the server. The logging in Powershell and eventviewer where not that clear.
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).
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.