I've recently updated my computer and graphics driver to the latest version, and GitHub does not run anymore. Running it will cause GitHub to crash. I assume that GitHub has been unintentionally broken.
Here's the application error log.
Faulting application name: GitHub.exe, version: 3.0.12.0, time stamp: 0x56a69eea
Faulting module name: amdocl.dll, version: 10.0.1912.5, time stamp: 0x567ac8c3
Exception code: 0xc0000005
Fault offset: 0x0023525b
Faulting process id: 0x1608
Faulting application start time: 0x01d15c401c7bc7b1
Faulting application path: C:\Users\Bryan See\AppData\Local\Apps\2.0\XAE6DH98.VQY\H58NHLOV.P2N\gith..tion_317444273a93ac29_0003.0000_20a3dfa4ba8ba894\GitHub.exe
Faulting module path: C:\WINDOWS\SYSTEM32\amdocl.dll
Report Id: b3979569-4ead-4baf-8df7-9e7677ee1412
Faulting package full name:
I had to assume that the AMD driver is causing this, as I'm running Windows 10 64-bit with virtual desktop resolution is enabled. However, I couldn't get in touch with the support team at GitHub.
Related
In the Event Log:
Application: xxx.exe
Framework Version: 0.0.0.0
Exception code: 0xc0000005
Fault offset: 0x0000000000df7bf3
Faulting process id: 0x1e60
Faulting application start time: 0x01d82e8d9c60d092
Faulting application path: : C:\Program Files (x86)\xxx.exe
Faulting module path: : C:\Program Files (x86)\xxx.exe
I'm not sure why the faulting module path is for the our exe. Before this issue happened, I was having a faulting module path of QT5Core.dll.
After I fixed that QT5Core.dll error, this crash happened.
Can I have some clue on what might caused this?
The application runs fine on a developing environment, but crashed in deploying environment.
I install Mongodb 4.0 on Windows Server 2012 R2 server, but I cannot start the service. Looking at the system log there are error as below
Product: MongoDB 4.0.0 2008R2Plus SSL (64 bit) -- Error 1920. Service 'MongoDB Server' (MongoDB) failed to start. Verify that you have sufficient privileges to start system services.
and
Faulting application name: mongod.exe, version: 4.0.0.0, time stamp: 0x5b2c1668
Faulting module name: i-ms-win-crt-runtime-l1-1-0.dll, version: 6.3.9600.17415, time stamp: 0x5450559e
Exception code: 0xc0000135
Fault offset: 0x00000000000ec5a0
Faulting process id: 0x25f8
Faulting application start time: 0x01d4284df2a95fad
Faulting application path: C:\Program Files\MongoDB\Server\4.0\bin\mongod.exe
Faulting module path: i-ms-win-crt-runtime-l1-1-0.dll
Report Id: 3056be2a-9441-11e8-80bb-d0946652c910
Faulting package full name:
Faulting package-relative application ID:
Do you have any hint to fix this problem?
From the docs, guide to install MongoDB on Windows, they have mentioned to have the updated windows or at least have KB2999226 update for Windows 2012 Server and Windows 10 to provide universal C runtime support for Windows.
They have another required update for Windows Server 2008 R2 and Windows 7 also.
I had the same problem when I install MongoDB on WIndows 7. The issue was resolved when I install newest updates fow Windows 7.
I've got a server running around 500 powershell processes. Each of these processes are designed to make WMI calls across our environment. I've been careful to verify that I do not use up all of the server's available memory or CPU. When I have all 500 processes running, I'm at around 70% memory usage.
Just in case anybody is wondering how the individual processes are handled, they are executed using a gearman job worker. Basically a shell python script that calls a powershell script...times 500.
The issue i'm running into is that some of my powershell processes are crashing after running a few hours.
Some of the errors that I'm getting are:
A new guard page for the stack cannot be created
When I open event viewer, I see these events when processes crash
Fault bucket , type 0
Event Name: PowerShell
Response: Not available
Cab Id: 0
Problem signature:
P1: powershell.exe
P2: 6.3.9600.16394
P3: System.OutOfMemoryException
P4: System.OutOfMemoryException
P5: oft.PowerShell.ConsoleHost.ReportExceptionFallback
P6: lization.EncodingTable.nativeCreateOpenFileMapping
P7: Consol.. main thread
P8:
P9:
P10:
Attached files:
These files may be available here:
C:\path
Analysis symbol:
Rechecking for solution: 0
Report Id: ID
Report Status: 2048
Hashed bucket:
I'm guessing it has something to do with powershell running out of memory, but the server is not peaked, and not all processes crash, it is sporadic.
Any help would be appreciated.
Here are more crash results, the powershell fault module names are different from time to time:
Problem Event Name: APPCRASH
Application Name: powershell.exe
Application Version: 6.3.9600.16384
Application Timestamp: 52158733
Fault Module Name: ntdll.dll
Fault Module Version: 6.3.9600.16408
Fault Module Timestamp: 523d45fa
Exception Code: c00000fd
Exception Offset: 00069abb
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 1033
Additional Information 1: 624b
Additional Information 2: 624b484d3cf74536f98239c741379147
Additional Information 3: a901
Additional Information 4: a901f876e92d1eb79eb3a513defef0c6
Problem signature:
Problem Event Name: APPCRASH
Application Name: powershell.exe
Application Version: 6.3.9600.16384
Application Timestamp: 52158733
Fault Module Name: combase.dll
Fault Module Version: 6.3.9600.16408
Fault Module Timestamp: 523d3001
Exception Code: c00000fd
Exception Offset: 0001a360
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 1033
Additional Information 1: 81ca
Additional Information 2: 81cae32566783b059420874b47802c3e
Additional Information 3: b637
Additional Information 4: b6375e6f6a866fc9d00393d4649231b8
have you looked at your max memory allocation per shell?
get-item WSMan:\localhost\Shell\MaxMemoryPerShellMB
and if its too low changing this;
set-item WSMan:\localhost\Shell\MaxMemoryPerShellMB 2048
Doesn't .Net have a limit of memory?
If you're using TaskManager to check on memory usage, you might try Process Explorer instead. It sometimes gives very different results.
Thanks everyone for the responses, it turns out that I had a memory leak in my powershell code that was causing memory usage to spike every now and then. Since I was not watching the server at every second, I missed when the memory usage spiked.
An interesting note, it appears that Powershell will not use more then 80% of available memory on a server before killing its own processes.
I had to increase the available memory to 56GB and now I'm not running into any issues whatsoever. I've been running 600 powershell processes for a week now and have not had one crash on me.
The issue occurs when executing EF 6.1.2 code first migrations in an Azure Web Role (WS 2012 R2). The same migrations run fine locally, even if I point the connection string to the (Azure) Sql Database.
The StackOverflowException is thrown by Entity Framework code, and the first line of ANY of my migrations doesn´t even get hit.
I have tried running the migrations in three different ways:
DbMigrator migrator = new DbMigrator(configuration);
migrator.Update(); // Here the exception is thrown
second:
DbMigrator migrator = new DbMigrator(configuration);
pendingMigrations = migrator.GetPendingMigrations().ToList();
foreach (string pendingMigration in pendingMigrations)
{
migrator.Update(pendingMigration); // Here the exception is thrown
}
and using web.config:
<contexts>
<context type="Superb.WorkNextDoor.EFRepository.Context.WndDbContext, Superb.WorkNextDoor.EFRepository, Version=1.0.0.0, Culture=neutral">
<databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[Superb.WorkNextDoor.EFRepository.Context.WndDbContext, Superb.WorkNextDoor.EFRepository], [Superb.WorkNextDoor.EFRepository.Migrations.Migrations.WndDbMigrationsConfiguration, Superb.WorkNextDoor.EFRepository.Migrations]], EntityFramework">
</databaseInitializer>
</context>
</contexts>
I see the StackOverflowException in Visual Studio when I´m remote debugging the web role. An error is recorded in windows event log of the web role (log info at the bottom of this post).
I have two migrations. I have tried running the first one from PMC and the second from the web role but no luck.
I have tried installing .Net 4.5.2 on the server, changing the VM size from XS to S and downgrading EF to version 6.1.1. Nothing worked. Also, I tried downloading the folder "E:\sites\0" from the web role to my local computer, installed the app on IIS and attached my VS Debugger and it doesn't throw that exception. There has got to be something different between my Windows 8.1 and that Windows Server 2012 R2.
I have spent a lot of time trying different things but I don´t want to give up on this and have to execute my migrations from package manager console.
Log Name: Application Source: Application Error Date:
1/11/2015 3:21:42 AM Event ID: 1000 Task Category: (100) Level:
Error Keywords: Classic User: N/A Computer:
RD0003FF508F5B Description: Faulting application name: w3wp.exe,
version: 8.5.9600.16384, time stamp: 0x5215df96 Faulting module name:
clr.dll, version: 4.0.30319.34014, time stamp: 0x52e0b86c Exception
code: 0xc00000fd Fault offset: 0x0000000000195499 Faulting process id:
0xc60 Faulting application start time: 0x01d02d4d77fdfb93 Faulting
application path: d:\windows\system32\inetsrv\w3wp.exe Faulting module
path: D:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Report
Id: f5e4d6dc-9940-11e4-80bd-0003ff508f5b Faulting package full name:
Faulting package-relative application ID: Event Xml:
1000
2
100
0x80000000000000
467
Application
RD0003FF508F5B
w3wp.exe
8.5.9600.16384
5215df96
clr.dll
4.0.30319.34014
52e0b86c
c00000fd
0000000000195499
c60
01d02d4d77fdfb93
d:\windows\system32\inetsrv\w3wp.exe
D:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
f5e4d6dc-9940-11e4-80bd-0003ff508f5b
Easy steps to reproduce this error:
Download this sample project: http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework-in-an-asp-net-mvc-application
Add a CloudServiceProject to the solution and add the web project as a web role
Publish it to azure
Browse the web site and go to students tab (this hits the database and the initializer tries to execute the migrations).
Happens the same.
This is identified as a bug in Microsoft Visual Studio 2013 Update 4. As a temporary work around disable "Lazy Initialization" under IntelliTrace Settings -> IntelliTrace Events. We are investigating fixing this bug in a future update for Visual Studio 2013.
The responsible for the StackOverflowException turned out to be IntelliTrace. I don't know the root cause of the issue between IntelliTrace and Code First Migrations that cause this behavior but when I downloaded the IntelliTrace logs I could see a lot of Sql exceptions:
I have already lost a lot of time with this so I won't investigate it further. The easiest workaround for me now is just disable IntelliTrace before deploying my Web Roles:
If somebody is curious, here are the IntelliTrace logs.
I hope this helps someone else solve such a problem without losing as much time as I did.
I am getting the following exception on Windows 8. However it works on Windows 7 environment. It looks this exception is thrown by comctl32.dll. I had gone through the below which has issue with the tooltip not with the comboxbox.
AccessViolationException on ToolTip that faults COMCTL32.dll - .NET 4.0
Application: Application.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)
at System.Windows.Forms.NativeWindow.DefWndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control.DefWndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control.WmCommand(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.ComboBox.WndProc(System.Windows.Forms.Message ByRef)
at CCS.UserInterface.MetaComboBox.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
at <Application>.MainApplication.Load(Splash)
at <Application>.Program.Main(System.String[])
Faulting application name: CCSEnterprise.exe, version: 4.354.4.15321, time stamp: 0x53dfe4c1
Faulting module name: comctl32.dll, version: 6.10.9600.17031, time stamp: 0x5308889d
Exception code: 0xc0000005
Fault offset: 0x00051a6e
Faulting process id: 0x13f8
Faulting application start time: 0x01cfb08bc91cf716
Faulting application path: C:\355AAA\Application.exe
Faulting module path: C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.9600.17031_none_a9efdb8b01377ea7\comctl32.dll
Report Id: 2284a19e-1c7f-11e4-be73-1078d298a609
Faulting package full name:
Faulting package-relative application ID:
I found that this problem occurs (crash) not only in WPF, but for WinForms.
It is hard to say what is the source of the problem, but still it appears that Microsoft dll related to OpenFileDialog has bugs (for me, it was ComDlg32.dll, OpenFileDialog, ShowDialog() call)
The only way I could call ShowDialog() function was to wrap it in the event and call with the help of
this.BeginInvoke(
new Action<YourObject, EventArgs>(YourObject_FileDialogOpened), new object[]
{ YourObjectInstance, e });
where "this" is a Control (for example, Form).
BeginInvoke(...) grants that you call will be process in a proper way.
Problem will not appear if you use call of the OpenFileDialog under button click event or any other similar scenario.
We've started experiencing the same issue, but only since 5th May 2016. Client installations that haven't been touched in years started crashing with access violations in comctl32.dll.
It turns out that AVG (the antivirus software) is somehow causing this issue. There are other forums and threads reporting similar issues.
For our application, 2 things worked;
1) run in XP SP3 compatibility mode (even on Windows 8 or 10)
OR
2) disable AVG