Due to work I'm doing I need to have latest SQL Server installed on my laptop, SQL Server Management Studio and Visual Studio 2017 Dev (all latest versions available as of today on Microsoft site(s) for download).
Everything works fine until I install VS 2017 (with a lot of options - total install comes to about 50GB, reflecting work being done). When that's done, SSMS crashes when I switch between tabs. Yes. I have opened query A in tab A, then Query B in tab B (connection to same server) and when I click query B that just loaded (double-click in Windows Explorer and using default association of .sql files) - boom: no error message, no warning. SSMS shows turning wheel for 5 sec and then it restarts.
Obviously it's unusable at this point, but did anyone had similar issue and tracked down the cause before I nuke the Windows and reinstall all from scratch?
Already tried SSMS repair, VS repair, SSMS reinstall, VS reinstall, SSMS uninstall then reinstall, SQl uninstall + SSMS unisntall + VS uninstall (had problems as VS installer wanted to be updated, then could not uninstall whole VS, had to do it app-by-app manually), then reinstalled in Microsoft suggested order: SQL Server, SSMS, VS. Again - worked fine until VS installation got done...
Any help appreciated.
After further investigation: one of the tabs needs to be pinned for the crash to occur. But the moment I pin any tab... all gone. So there may be no link between SSMS and VS, but replicated that 3 times now: open tab, pin, open another tab, click on first, then back on second and crash.
After some time and further investigation (11 Oct 2018):
The issue happened to me again. But at the moment it's unclear if it's DisplayPort or Displaylink to DP (as I'm still using port replicator, utilizing DisplayLink solution), that is the cause, as my laptop does not have DP out, just HDMI. I also can't replicate problem on other workstations without breaking things for other people, too.
The link to DisplayPort is still there, so switching to HDMI continues to be a valid workaround (as in my answer below), but the issue is definitely software in origin, related to Visual Studio in some way. Or at least what's shown in the event viewer for this error:
Application: Ssms.exe Framework Version: v4.0.30319 Description: The
process was terminated due to an unhandled exception. Exception Info:
System.ArgumentException at System.Windows.Rect.set_Height(Double)
at
Microsoft.VisualStudio.PlatformUI.Shell.DraggedTabInfo.NormalizeTabHeight()
at
Microsoft.VisualStudio.PlatformUI.Shell.DraggedTabInfo.ExpandTabStripCore()
at
Microsoft.VisualStudio.PlatformUI.Shell.DraggedTabInfo.MeasureTabStrip()
at
Microsoft.VisualStudio.PlatformUI.Shell.Controls.DockPreviewWindow.OnPanelLayoutUpdated(System.Object)
at
Microsoft.VisualStudio.PlatformUI.Shell.Controls.DockPreviewWindow.OnPanelLayoutUpdated(System.Object,
System.Windows.RoutedEventArgs) at
System.Windows.RoutedEventHandlerInfo.InvokeHandler(System.Object,
System.Windows.RoutedEventArgs) at
System.Windows.EventRoute.InvokeHandlersImpl(System.Object,
System.Windows.RoutedEventArgs, Boolean) at
System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject,
System.Windows.RoutedEventArgs) at
System.Windows.UIElement.RaiseEvent(System.Windows.RoutedEventArgs)
at
Microsoft.VisualStudio.PlatformUI.Shell.Controls.ReorderTabPanel.OnLayoutUpdated(System.Object,
System.EventArgs) at
System.Windows.ContextLayoutManager.fireLayoutUpdateEvent() at
System.Windows.ContextLayoutManager.UpdateLayout() at
System.Windows.ContextLayoutManager.UpdateLayoutCallback(System.Object)
at System.Windows.Media.MediaContext+InvokeOnRenderCallback.DoWork()
at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
at
System.Windows.Media.MediaContext.RenderMessageHandlerCore(System.Object)
at
System.Windows.Media.MediaContext.RenderMessageHandler(System.Object)
at
System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate,
System.Object, Int32) at
System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object,
System.Delegate, System.Object, Int32, System.Delegate) at
System.Windows.Threading.DispatcherOperation.InvokeImpl() at
System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(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.ExecutionContext.Run(System.Threading.ExecutionContext,
System.Threading.ContextCallback, System.Object) at
MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext,
System.Threading.ContextCallback, System.Object) at
System.Windows.Threading.DispatcherOperation.Invoke() at
System.Windows.Threading.Dispatcher.ProcessQueue() at
System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr,
IntPtr, Boolean ByRef) at MS.Win32.HwndWrapper.WndProc(IntPtr,
Int32, IntPtr, IntPtr, Boolean ByRef) at
MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object) at
System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate,
System.Object, Int32) at
System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object,
System.Delegate, System.Object, Int32, System.Delegate) at
System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority,
System.TimeSpan, System.Delegate, System.Object, Int32) at
MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
Same laptop, same Windows installation as before, same SSMS and VS installations. What changed: different docking station (thunderbolt instead of USB3.0), the two external monitors (same model, but different specimens) are daisychained via DP, connected to single miniDisplayport output in the dock.
Until I reversed the order by which the daisy chain was working (so previously display number 2 is now display number 3, with laptop native remaining main display and number 1) all was well.
After the swap the problem returned. Since the monitors were recognized as new devices, they were set up as 1920x1080 resolution from their native 1920x1200 and to duplication instead of extended. When set it all up back to as I wanted, the error started again.
After some more investigations: found this thread:
https://feedback.azure.com/forums/908035-sql-server/suggestions/33619039-crash-when-going-to-pinned-tab
and replicated the tip in there. After some more testing issue has been narrowed down to Displayport - the culprit monitor is connected to laptop via USB port replicator, which can output display to three monitors (2xHDMI and 1xDP). When changed connection of the offending monitor from DP to HDMI issue is gone.
Related
my project using QTcpSocket and the function setSocketDescriptor(). The code is very normal
QTcpSocket *socket = new QTcpSocket();
socket->setSocketDescriptor(this->m_socketDescriptor);
This coding worked fine most of the time until I ran a performance testing on Windows Server 2016, the crash occurred. I debugging with the crash dump, here is the log
0000004f`ad1ff4e0 : ucrtbase!abort+0x4e
00000000`6ed19790 : Qt5Core!qt_logging_to_console+0x15a
000001b7`79015508 : Qt5Core!QMessageLogger::fatal+0x6d
0000004f`ad1ff0f0 : Qt5Core!QEventDispatcherWin32::installMessageHook+0xc0
00000000`00000000 : Qt5Core!QEventDispatcherWin32::createInternalHwnd+0xf3
000001b7`785b0000 : Qt5Core!QEventDispatcherWin32::registerSocketNotifier+0x13e
000001b7`7ad57580 : Qt5Core!QSocketNotifier::QSocketNotifier+0xf9
00000000`00000001 : Qt5Network!QLocalSocket::socketDescriptor+0x4cf7
00000000`00000000 : Qt5Network!QAbstractSocket::setSocketDescriptor+0x256
In the stderr log, I see those logs
CreateWindow() for QEventDispatcherWin32 internal window failed (Not enough storage is available to process this command.)
Qt: INTERNAL ERROR: failed to install GetMessage hook: 8, Not enough storage is available to process this command.
Here is the function, where the code was stopped on the Qt codebase
void QEventDispatcherWin32::installMessageHook()
{
Q_D(QEventDispatcherWin32);
if (d->getMessageHook)
return;
// setup GetMessage hook needed to drive our posted events
d->getMessageHook = SetWindowsHookEx(WH_GETMESSAGE, (HOOKPROC) qt_GetMessageHook, NULL, GetCurrentThreadId());
if (Q_UNLIKELY(!d->getMessageHook)) {
int errorCode = GetLastError();
qFatal("Qt: INTERNAL ERROR: failed to install GetMessage hook: %d, %s",
errorCode, qPrintable(qt_error_string(errorCode)));
}
}
I did research and the error Not enough storage is available to process this command. maybe the OS (Windows) does not have enough resources to process this function (SetWindowsHookEx) and failed to create a hook, and then Qt fire a fatal signal, finally my app is killed.
I tested this on Windows Server 2019, the app is working fine, no crashes appear.
I just want to know more about the meaning of the error message (stderr) cause I don't really know what is "Not enough storage"? I think it is maybe the limit or bug of the Windows Server 2016? If yes, is there any way to overcome this issue on Windows Server 2016?
The error ‘Not enough storage is available to process this command’ usually occurs in Windows servers when the registry value is set incorrectly or after a recent reset or reinstallations, the configurations are not set correctly.
Below is verified procedure for this issue:
Click on Start > Run > regedit & press Enter
Find this key name HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
Locate IRPStackSize
If this value does not exist Right Click on Parameters key and Click on New > Dword Value and type in IRPStackSize under the name.
The name of the value must be exactly (combination of uppercase and lowercase letters) the same as what I have above.
Right Click on the IRPStackSize and click on Modify
Select Decimal enter a value higher than 15(Maximum Value is 50 decimal) and Click Ok
You can close the registry editor and restart your computer.
Reference
After researching for a few days I finally can configure the Windows Server 2016 setting (registry) to prevent the crash.
So basically it is a limitation of the OS itself, it is called desktop heap limitation.
https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/desktop-heap-limitation-out-of-memory
(The funny thing is the error message is Not enough storage is available to process this command but the real problem came to desktop heap limitation. )
So for the solution, flowing the steps in this link: https://learn.microsoft.com/en-us/troubleshoot/system-center/orchestrator/increase-maximum-number-concurrent-policy-instances
I increased the 3rd parameter of SharedSection to 2048 and it fix the issue.
Summary steps:
Desktop Heap for the non-interactive desktops is identified by the third parameter of the SharedSection= segment of the following registry value:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows
The default data for this registry value will look something like the following:
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16
The value to be entered into the Third Parameter of the SharedSection= segment should be based on the calculation of:
(number of desired concurrent policies) * 10 = (third parameter value)
Example: If it's desired to have 200 concurrent policy instances, then 200 * 10 = 2000, rounding up to a nice memory number gives you 2048as the third parameter resulting in the following update to be made to the registry value:
SharedSection=1024,3072,2048
Tried https://stackoverflow.com/a/30138664/533237 and able to capture screen.
But I want to capture screen from an application running in session 0 or another user.Introduced a 10 sec sleep before capturing and switched to another user.
Also tried PsExec.exe -h -s E:\sc.exe. Both throws error
C:\Users\unity\Documents\Visual Studio 2015\Projects\ConsoleApplication2\Debug>sc.exe
FAILURE 0x8876086C (-2005530516)
line: 60 file: 'c:\users\unity\documents\visual studio 2015\projects\consoleapplication2\consoleapplication2\consoleapplication2.cpp'
expr: 'd3d->GetAdapterDisplayMode(adapter, &mode)'
C:\Users\unity\Documents\Visual Studio 2015\Projects\ConsoleApplication2\Debug>PsExec.exe -h -s E:\sc.exe -w E:\
PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
FAILURE 0x8876086C (-2005530516)
line: 60 file: 'c:\users\unity\documents\visual studio 2015\projects\consoleapplication2\consoleapplication2\consoleapplication2.cpp'
expr: 'd3d->GetAdapterDisplayMode(adapter, &mode)'
Commented out GetAdapterDisplayMode and hardcoded height and width but CreateDevice failed
FAILURE 0x8876086A (-2005530518)
line: 76 file: 'c:\users\unity\documents\visual studio 2015\projects\consoleapplication2\consoleapplication2\consoleapplication2.cpp'
expr: 'd3d->CreateDevice(adapter, D3DDEVTYPE_HAL, NULL, D3DCREATE_SOFTWARE_VERTEXPROCESSING, ¶meters, &device)'
Edited:
Idea is to have a single app running in background and capture anything getting displayed irrespective of the user logged in or even if no one is logged in (lock/login screen)
There are two levels of problems with this.
On one level, while a lot of GDI will work, session 0 is not linked to a functional display device, certainly not one that is capable of D3D.
On another level, while things like the DWM have been introduced, the Windows API has always presented a display model where invisible screen pixels simply don't exist. The entire windows display model is built around getting windows to co-operative paint to a shared display surface, and any parts of a window that are uncovered are repainted on demand by the desktop composition system.
This means, in a very fundamental way, you cannot screen capture anything from session 0 as, in order to do so, session 0 would have to be attached to the active display device.
I'm running a django-celery application on Ubuntu-12.04.
When I run a celery task from my web interface, I get the following error, taken form postgresql-9.3 logfile (maximum level of log):
2013-11-12 13:57:01 GMT tss_usr 8113 LOG: could not receive data from client: Connection reset by peer
tss_usr is the postgresql user of the django application database and (in this example) 8113 is the pid of the process who killed the connection, I guess.
Have you got any idea on why this happens or at least how to debug this issue?
To make things work again I need to restart postgresql which is extremely uncomfortable.
I know this is an older post, but I just found it because I had the same error today in my postgres logs. I narrowed it down to a PDO select statement. I'm using Zend Framework 1.10.3 on Ubuntu Precise.
The following pdo statement generated an error if $opinion is a long text string. The column opinion is type Text in my postgres table. The query succeeds if $opinion is under a certain number of characters. 1000 characters works fine. 2000 characters fails with "could not receive data from client: Connection reset by peer".
$select = $this->db->select()
->from( 'datauserstopics' )
->where("opinion = ?",trim($opinion))
->where("datatopicsid = ?",trim($tid))
->where("datausersid= ?",$datausersid);
$stmt = $this->db->query($select);
I circumvented the problem by using:
->where("substr(opinion,1,100) = ?",trim(substr($opinion,1,100)))
This is not a perfect solution, but for my purposes, the select statement using substr() suffices.
Note that I have no problem inserting long strings into the same table/column. The disconnect problem only appears for me on the PDO select with relatively long text strings.
I'm getting it in 2017 with 9.4, I have no text fields, don't know what a PDO is. My select statement is about 50 bytes long, I'm trying to fetch an int4 and a double precision. I suspect the error message can mean multiple things.
I've since found https://dba.stackexchange.com/questions/142350/postgres-could-not-receive-data-from-client-connection-reset-by-peer which indicates it could be a problem with the client configuration. My client is libpg and PQconnectdb() is giving me a CONNECTION_OK return. It works at least partly.
For me, restarting the hypervisor where both the Postgres and the application using it helped. I've seen stack traces in dmesg before, though.
I'm using the parallel computing toolbox (PCT) in combination with the Simbiology toolbox in MATLAB 2012b. I’m receiving an intermittent error message when I run my script with a remote pool of workers, but not with a local pool of workers:
Caught std::exception Exception message is:
vector::_M_range_check
Error using parallel_function (line 589)
Error in remote execution of remoteParallelFunction : RUNTIME_ERROR
Error in PSOFit (line 486)
parfor ns = 1:r.NumSwp
Error in PSOopt_driver (line 209)
PSOFit(ObjFuncName,LB,UB,PSOopts);
The error does not occur when I comment out the call to the function sbiosimulate (a SimBiology function for model evaluation).
I have a couple of ideas:
I’ve introduced some sort of race condition, that causes a problem in accessing the model variables (is this possible in MATLAB?)
Model compilation in simbiology is sometimes but not always compatible with the PCT, and I’ve hit some sort of edge case
Since sbiosimulate evaluates compiled C++ code, for some inputs there might be a bug in the source that generates the exception
I am aware of this.
I'm a developer of SimBiology. I believe this is a bug that was introduced into SimBiology's C++ code in the R2012a release. The bug is triggered when a simulation ends without producing any simulation results. This can sometimes occur when the model is configured to report only particular times (using the OutputTimes options) AND the simulation is configured to end after a particular amount of real time (using the MaximumWallClock option). Basically, the simulation "times out" before it ever gets a chance to log the first output time.
One way to work around this problem is to always include time 0 in the OutputTimes. This time will always get logged before evaluating the MaximumWallClock criterion, preventing the bug from getting triggered. I am also contacting this user directly and will work on fixing the bug in a future release.
I hope following explanation will make sense because it's a weird problem we're facing and hard to describe.
We have a maven project which gets build in hudson and that contains some unit tests where dates are used and asserted. The hudson server runs on solaris. Now, occasionally (like 30% of the times) the unit tests using dates fail because 3,5 hours are deducted from the specified time in the unit test and hence asserts start failing. The other 70% everything works fine although nothing at all changed in the code and we run the hudson job several times an hour.
I add following code to a unittest to check the time:
#Test
public void testDate() {
System.out.println("new DateMidnight(2011, 1, 5).toDate();");
System.out.println(new DateMidnight(2011, 1, 5).toDate());
System.out.println(new DateMidnight(2011, 1, 5).toDate().getTime());
Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 2011);
cal.set(Calendar.MONTH, 0);
cal.set(Calendar.DAY_OF_MONTH, 5);
cal.set(Calendar.HOUR, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
System.out.println("cal.getTime();");
System.out.println(cal.getTime());
System.out.println(cal.getTime().getTime());
}
So basically it should print the same thing when using jodatime or plain old Calendar. This is the case in 70% of the runs; for the other 30% I get following printouts:
Running TestSuite
new DateMidnight(2011, 1, 5).toDate();
Tue Jan 04 21:30:00 MET 2011
1294173000000
cal.getTime();
Wed Jan 05 12:00:00 MET 2011
1294225200000
So, Calendar keeps the correct date and time but jodatime deducts 3,5 hours.
Local maven tests never appear the pose this problem and we can't figure out what could be the cause of it. Especially, we can't think of a single reason why the tests sometimes pass and sometimes fail without changing any code nor hudson or server setting.
Also, we run the maven install with cobertura which means that the unit tests are run twice. It happens also that they pass the first time and fail the second time or the other way around or that they fail both times.
Thanks for any solutions or tips to track down the cause,
Stijn
You may also be running into some version of SUREFIRE-533, which should be solvable by setting the TZ environment variable in the environment that is running hudson. Please report back on the issue if this helps.
Perhaps Hudson is running on 3 servers, and 1 has a different version of the time zone data in the JDK from the other 2? (check the JVM version in detail). Remember that Joda-Time also has its own version of the time-zone data, and the two may be different.
The problem seems to be fixed now.
We've upgraded our jodatime version from 5.14.2 to 5.14.6.
Since then I ran the build on auto each half hour so after about a 100 runs we never encountered this problem again.