I recently upgraded my pc to Windows 10 and for the most part everything seemed to be working fine. Powershell was working fine until I opened up a shell and got this error
Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Management.Automation.LocationGlobber.GetProviderPath(String path, CmdletProviderContext context)
at System.Management.Automation.LocationGlobber.ResolveDriveQualifiedPath(String path, CmdletProviderContext context, Boolean allowNonexistingPaths, CmdletProvider& providerInstance)
at System.Management.Automation.LocationGlobber.GetGlobbedMonadPathsFromMonadPath(String path, Boolean allowNonexistingPaths, CmdletProviderContext context, CmdletProvider& providerInstance)
at System.Management.Automation.SessionStateInternal.SetLocation(String path, CmdletProviderContext context)
at System.Management.Automation.Runspaces.InitialSessionState.SetSessionStateDrive(ExecutionContext context, Boolean setLocation)
at System.Management.Automation.AutomationEngine..ctor(PSHost hostInterface, RunspaceConfiguration runspaceConfiguration, InitialSessionState iss)
at System.Management.Automation.Runspaces.LocalRunspace.DoOpenHelper()
at System.Management.Automation.Runspaces.RunspaceBase.CoreOpen(Boolean syncCall)
at Microsoft.PowerShell.ConsoleHost.OpenConsoleRunspace(Runspace runspace, Boolean staMode)
at Microsoft.PowerShell.ConsoleHost.DoCreateRunspace(String initialCommand, Boolean skipProfiles, Boolean staMode, Boolean importSystemModules, Collection`1 initialCommandArgs)
at Microsoft.PowerShell.ConsoleHost.CreateRunspace(Object runspaceCreationArgs)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
causing the prompt to show me a "Windows PowerShell has stopped working" popup. I tried running the shell as an admin and restarting my computer, waiting for the memory in RAM to decay. Is there an easy fix, such as reinstalling a framework, or would I need to buy a new RAM chip for my machine?
Machine specs:
Lenovo Yoga 13 (1st gen)
8GB RAM (originally came with 4, I upgraded)
104 GB Storage
Intel core i5-3337U # 1.80 GHz
64 bit
UPDATE
Going to the file location, I was able to open PowerShell(x86) with no problems. I can execute commands but I'd prefer to solve the regular PowerShell if possible.
Related
I had visual studio running while my HDD was unknowingly running out of available space, I have since cleared the issue and the HDD has multiple gigabytes of data free, but sadly something got broken during this unstable state, and I am receiving this error:
Recoverable
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.VisualStudio.ProjectSystem.ProjectSerialization.CachedMsBuildGlobWithGaps.IsMatch(String stringToMatch)
at System.Linq.ImmutableCollectionsExtensions.Any[TElement,TArg(ImmutableArray\`1 immutableArray, Func\`3 predicate, TArg arg)
at System.Linq.ImmutableCollectionsExtensions.Any[TElement,TArg(ImmutableArray\`1 immutableArray, Func\`3 predicate, TArg arg)
at Microsoft.VisualStudio.ProjectSystem.ProjectSerialization.ConstructionUtilities.<>c__DisplayClass16_0.<CheckIfProjectConeChangedOnDisk>b__1(FileSystemEntry&entry)
at Microsoft.IO.Enumeration.FileSystemEnumerator\`1.MoveNext()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable\`1 source)
at Microsoft.VisualStudio.ProjectSystem.ProjectSerialization.ConstructionUtilities.CheckIfProjectConeChangedOnDisk(String projectPath, DateTime lastEvaluationTimeUtc, IEnumerable\`1 globs, IProjectTelemetryService telemetryService, UnconfiguredProject project)
at Microsoft.VisualStudio.ProjectSystem.ProjectSerialization.ProjectCacheService.IsProjectCacheUpToDateSlow(ConfiguredProject configuredProject)
I have a program that was developed with C#/.NET 4.5.2 and runs fine on Windows (7 x64). The program handles a large amount of data, so it is compiled for x64 only. My largest input dataset can be processed on a PC with 16GB RAM.
When I try to run it on Ubuntu 16.04 LTS 64 bit; 64 GB RAM installed, everything is fine for smaller datasets but I started getting SIGSEGV signals with larger datasets. These errors do not always occur at the same position, and for intermediate sized datasets, they sometimes don't occur at all.
I upgraded my version of Mono so I am now running with 5.0.1.1:
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen (concurrent by default)
Upgrading replaced the error with a NullReferenceException:
Native stacktrace:
Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
at (wrapper managed-to-native) System.Array:FastCopy (System.Array,int,System.Array,int,int)
at System.Array.Copy (System.Array sourceArray, System.Int32 sourceIndex, System.Array destinationArray, System.Int32 destinationIndex, System.Int32 length) [0x00068] in <a07d6bf484a54da2861691df910339b1>:0
at System.Collections.Generic.HashSet`1[T].SetCapacity (System.Int32 newSize, System.Boolean forceNewHashCodes) [0x0000f] in <26aedeede9534b948c539f8734c8492d>:0
at System.Collections.Generic.HashSet`1[T].IncreaseCapacity () [0x00025] in <26aedeede9534b948c539f8734c8492d>:0
at System.Collections.Generic.HashSet`1[T].AddIfNotPresent (T value) [0x000bc] in <26aedeede9534b948c539f8734c8492d>:0
at System.Collections.Generic.HashSet`1[T].Add (T item) [0x00000] in <26aedeede9534b948c539f8734c8492d>:0
at MyLib.MyClass.DoProcessing () [0x00a6e] in <66a585adc1684679bfec565c73eb94e4>:0
at MyLib.MyClass.SynchProcessing () [0x00000] in <66a585adc1684679bfec565c73eb94e4>:0
at MyApp.Program.Main (System.String[] args) [0x00139] in <e80b0468d8e642129fa7c39d5b2bb0a0>:0
In addition to HashSet< long >, it sometimes appears in Dictionary < long , Node > (where Node is a small class of two floats), but either way it is always when it is trying to add an element and in System.Array:FastCopy. This same location was reported by the older version of Mono when it gave a SIGSEGV. The errors occur in a single-threaded section of the code where the data is being read in & pre-processed (later it is multi-threaded, but that code has yet to produce the error, probably because all collections are already at their max size or shrinking)
So it looks like an internal pointer is being corrupted when a HashSet or Dictionary's underlying array is re-allocated.
Has anyone seen anything like this? I think it looks like a memory manager / Garbage Collector error, or even an underlying bug in Mono? However, searching Google and this site has not turned anything up. I see that Mono has a new GC but mono -V says it is running be default (and the SIGSEGV was being produced when the older version was being used).
Does anyone have any suggestions or solutions to try?
I don't know the heap & collection sizes when this error occurs. Next up I'll add some diagnostics to try and help although they'll make it slow and only give approximate values (eg. Console.WriteLine every 10,000 nodes, say)
Later edit: After more investigation, the Windows Updates and the OpenGL DLL were red herrings. The cause of these symptoms was a LoadLibrary() call failing with GetLastError() == ERROR_NOT_ENOUGH_MEMORY. See my answer for how to solve such issues. Below is the original question for historical interest. /edit
A map viewer I wrote in Python/wxPython for Windows with a C++ backend suddenly
stopped working, without any code changes or even recompiling. The very same
executables had been working for weeks before (same Python, same DLLs, ...).
Now, when querying Windows for a pixel format to use with OpenGL (with
ChoosePixelFormat()), I get a MessageBox saying:
LoadLibrary failed with error 8:
Not enough storage is available to process this command
The error message is displayed when executing the following code fragment:
void DevContext::SetPixelFormat() {
PIXELFORMATDESCRIPTOR pfd;
memset(&pfd, 0, sizeof(pfd));
pfd.nSize = sizeof(pfd);
pfd.nVersion = 1;
pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL;
pfd.iPixelType = PFD_TYPE_RGBA;
pfd.cColorBits = 32;
int pf = ChoosePixelFormat(m_hdc, &pfd); // <-- ERROR OCCURS IN HERE
if (pf == 0) {
throw std::runtime_error("No suitable pixel format.");
}
if (::SetPixelFormat(m_hdc, pf, &pfd) == FALSE) {
throw std::runtime_error("Cannot set pixel format.");
}
}
It's actually an ATI GL driver DLL showing the message box. The relevant part of the call stack is this:
... More MessageBox stuff
0027e860 770cfcf1 USER32!MessageBoxTimeoutA+0x76
0027e880 770cfd36 USER32!MessageBoxExA+0x1b
*** ERROR: Symbol file not found. Defaulted to export symbols for C:\Windows\SysWOW64\atiglpxx.dll -
0027e89c 58471df1 USER32!MessageBoxA+0x18
0027e9d4 58472065 atiglpxx+0x1df1
0027e9dc 57acaf0b atiglpxx!DrvValidateVersion+0x13
0027ea00 57acb0f3 OPENGL32!wglSwapMultipleBuffers+0xc5e
0027edf0 57acb1a9 OPENGL32!wglSwapMultipleBuffers+0xe46
0027edf8 57acc6a4 OPENGL32!wglSwapMultipleBuffers+0xefc
0027ee0c 57ad5658 OPENGL32!wglGetProcAddress+0x45f
0027ee28 57ad5dd4 OPENGL32!wglGetPixelFormat+0x70
0027eec8 57ad6559 OPENGL32!wglDescribePixelFormat+0xa2
0027ef48 751c5ac7 OPENGL32!wglChoosePixelFormat+0x3e
0027ef60 57c78491 GDI32!ChoosePixelFormat+0x28
0027f0b0 57c7867a OutdoorMapper!DevContext::SetPixelFormat+0x71 [winwrap.cpp # 42]
0027f1a0 57ce3120 OutdoorMapper!OGLContext::OGLContext+0x6a [winwrap.cpp # 61]
0027f224 1e0acdf2 maplib_sip!func_CreateOGLDisplay+0xc0 [maps.sip # 96]
0027f240 1e0fac79 python33!PyCFunction_Call+0x52
... More Python stuff
I did a Windows Update two weeks ago and noticed some glitches (e.g. when
resizing the window), but my program still worked mostly OK. Just now I
rebooted, Windows installed 1 more update, and I don't get past
ChoosePixelFormat() any more. However, the last installed update was
KB2998527, a Russia timezone update?!
Things that I already checked:
Recompiling doesn't make it work.
Rebooting and running without other programs running doesn't work.
Memory consumption of my program is only 67 MB, I'm not out of memory.
Plenty of diskspace free (~50 GB).
The HDC m_hdc is obtained from the display panel's HWND and seems to be valid.
Changing my linker commandline doesn't work.
Should I update my graphics drivers or roll back the updates? Any other ideas?
System data dump: Windows 7 Ultimate SP1 x64, 4GB RAM; HP EliteBook 8470p; Python 3.3, wxPython 3.0.1.dev76673 msw (phoenix); access to C++ data structures via SIP 4.15.4; C++ code compiled with Visual Studio 2010 Express, Debug build with /MDd.
I was running out of virtual address space.
By default, LibTIFF reads TIF images by memory-mapping them (mmap() or CreateFileMapping()). This is fine for pictures of your wife, but it turns out it's a bad idea for gigabytes worth of topographic raster-maps of the Alps.
This was difficult to diagnose, because LibTIFF silently fell back to read() if the memory mapping failed, so there never was an explicit error before. Further, mapped memory is not accounted as working memory by Windows, so the Task-Manager was showing 67MB, when in fact nearly all virtual address space used up.
This blew up now because I added more TIF images to my database recently. LoadLibrary() started failing because it couldn't find any address space to put the new library. GetLastError() returned 8, which is ERROR_NOT_ENOUGH_MEMORY. That this happened within ATI's OpenGL library was just coincidence.
The solution was to pass "m" as flag to TiffOpen() to disable memory mapped IO.
Diagnosing this is easy with the Windows SysInternals tool VMMap (documentation link), which shows you how much of the virtual address space of a process is taken up by code/heap/stack/mapped files/shareable data/etc.
This should be the first thing to check if LoadLibrary() or CreateFileMapping() fails with ERROR_NOT_ENOUGH_MEMORY.
My project include 350 forms, 780 thousand lines of code (350 thousand designer code).
But when i want to design form, every two or three design VS gives "Exception of type 'System.OutofMemoryEception' was thrown" error.
I am restart the project and this error gone until rebuild or open a few form... I couldn' work over 5 minutes...
I am looking at memory usage : devenv.exe using 500/600 mb and my sistem using 1.9 GB ram of 4GB ram
I don't think so but is VS crash or not support 350 forms in project?
Is there any solution about VS memory options?
This is screenshot :
http://social.microsoft.com/Forums/getfile/22517/
My system spesifics is;
Intel Core i5 CPU
4 GB RAM
Operation system :Windows XP 32 bit (at the windows 7 problem is same)
Visual Studio 2010 Ultimate (at Visual Studio 2008 Professional SP1 problem is the same)
Call Stacks
at System.Reflection.AssemblyName.nGetFileInformation(String s)
at System.Reflection.AssemblyName.GetAssemblyName(String assemblyFile)
at Microsoft.VisualStudio.Design.VSTypeResolutionService.AssemblyEntry.get_AssemblyName()
at Microsoft.VisualStudio.Design.VSTypeResolutionService.AssemblyEntry.get_Assembly()
at Microsoft.VisualStudio.Design.VSTypeResolutionService.AssemblyEntry.Search(String fullName, String typeName, Boolean ignoreTypeCase, Assembly& assembly, String description)
at Microsoft.VisualStudio.Design.VSTypeResolutionService.SearchProjectEntries(AssemblyName assemblyName, String typeName, Boolean ignoreTypeCase, Assembly& assembly)
at Microsoft.VisualStudio.Design.VSTypeResolutionService.SearchEntries(AssemblyName assemblyName, String typeName, Boolean ignoreCase, Assembly& assembly, ReferenceType refType)
at Microsoft.VisualStudio.Design.VSTypeResolutionService.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase, ReferenceType refType)
at Microsoft.VisualStudio.Design.Serialization.CodeDom.AggregateTypeResolutionService.GetType(String name, Boolean throwOnError, Boolean ignoreCase)
at Microsoft.VisualStudio.Design.Serialization.CodeDom.AggregateTypeResolutionService.GetType(String name)
at System.ComponentModel.Design.Serialization.DesignerSerializationManager.GetType(String typeName)
at System.ComponentModel.Design.Serialization.DesignerSerializationManager.System.ComponentModel.Design.Serialization.IDesignerSerializationManager.GetType(String typeName)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeExpression(IDesignerSerializationManager manager, String name, CodeExpression expression)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeExpression(IDesignerSerializationManager manager, String name, CodeExpression expression)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializePropertyAssignStatement(IDesignerSerializationManager manager, CodeAssignStatement statement, CodePropertyReferenceExpression propertyReferenceEx, Boolean reportError)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeAssignStatement(IDesignerSerializationManager manager, CodeAssignStatement statement)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeStatement(IDesignerSerializationManager manager, CodeStatement statement)
You don't say whether you're running 32 or 64 bit XP. I would hazard a guess that you're running 32 and have just reached the limits of your PC. You'll only get around 2 Gigs virtual memory on most systems.
Either way I would seriously consider looking at restructuring your project as 350 WinForms seems pretty excessive to me. There must be some be some way in which you can reduce this to avoid duplication or to create class library projects that you can offload some of the functionality into.
You could give Solution Load Manager a try to mark projects and files as load on demand rather than on start up.
I am using RegisterWaitForSingleObject to wait on a serial comm events as registered with WaitCommEvent.
The code works well on Windows XP however always throws an exception somewhere in the treadpool when running on Windows 7.
The stack trace shows
ntdll.dll!_TppWaiterpThread#4() + 0x3a7ee bytes
kernel32.dll!#BaseThreadInitThunk#12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart#8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart#8() + 0x1b bytes
Is there any way to get this function to operate correctly in Windows 7 or will I need to re-write with support for the new Windows Vista/7 threadpool functions.
Here is an example of how I am calling the code. As stated this works flawlessly on XP
// Calback is on an object defined as a static function
class CommPortCallback
{
public:
static void WINAPI serialLayerCallback( PVOID lpParameter,
BOOLEAN TimerOrWaitFired )
{
....
}
};
// wait is registered later as such
RegisterWaitForSingleObject(&pWaitData->callbackHandle, m_readOverlapped,
CommPortCallback::serialLayerCallback, pBaseCallback,
INFINITE, WT_EXECUTEONLYONCE)
Show the code calling RegisterWaitForSingleObject.
At a guess, your callback function has the wrong calling convention or wrong parameter types, you're using a function pointer cast to overrule the compiler's complaint, and then the stack pointer is left misaligned after the call.
With the code the cause is now clear: You're passing in a pointer to the OVERLAPPED structure, instead of the event handle. It doesn't seem like this should ever have worked correctly on XP, but whether or not it crashes or fails silently could well vary with Windows version.