Archive
Fix: Windows Update 0x8e5e03fa, 0x800703fa errors
Sometime ago, I was receiving errors 0x8e5e03fa and 0x800703fa on several pending updates at Windows 10’s Update pane (found at Settings / Updates & Security / Windows Update from the Start menu).
The updates history wasn’t showing many more details, but could see Knowldege Base article numbers (KBxx) for some pending cummulative updates.
Trying to update some graphics drivers from the Device Manager (can access that by right clicking the Start menu button and selecting “Device Manager” from the popup menu shown on Windows 10), by right-clicking respective devices and selecting to update their drivers, was also failing.
So it did look like a systematic issue, not some issue with some specific update item.
Looked up the error code 0x8e5e03fa via Google and found this article mentioning a JET (database engine) error. That’s the same engine used in Access if I remember well, interesting that it’s getting used by Windows Update too (probably to maintain some private database).
The suggested fix didn’t work since the file mentioned in that article was not existing, but at that folder (%windir%\system32\catroot2) I found a dberr.txt file that obviously was holding some error log.
Printing out that file (can use TYPE dberr.txt | more to wait after each “page”), I couldn’t help but notice that it was writing JET error all over it.
I renamed that file (think it was then recreated again automatically) and also renamed the two folders there (using the move command – e.g. can type move, press TAB till the name of the folder appears and then add a minus sign and press TAB again till the same folder name appears and press ENTER). Did that while having the cryptsvc service stopped (using net stop cryptsvc command) as that article suggested. Then started the service again (using net start cryptsvc).
After doing this, all failing updates (some extra driver updates had been found using DriverBooster, but were also failing to install) eventually installed fine and Windows 10 started bringing more updates:
Fix: VSIX installer error – SignatureDescription could not be created
This is my answer at:
to the question on why some extensions fail to install at RC (Release Candidate) versions of Visual Studio 2015, showing error “SignatureDescription could not be created for the signature algorithm supplied”.
Not sure if Microsoft fixed this on purpose or by accident, but this is very useful for people who don’t have the time (and courage) to uninstall the RC version and reinstall the final one and all extensions they were using.
Speaking of reinstalling everything by hand, it would be nice if you could export an XML document containing a list of installed Visual Studio extensions and then be able to reimport it to install them all at an other Visual Studio installation (should also be able to edit that XML document to remove some if you wish, or at export see a checkbox list to deselect ones you don’t want exported in the resulting list).
To keep it short, the answer is:
Try installing http://go.microsoft.com/fwlink/?LinkID=619615 (found from http://blogs.msdn.com/b/somasegar/archive/2015/07/29/building-apps-for-windows-10-with-visual-studio-2015.aspx)
I used Custom installation option and selected everything. It upgraded Visual Studio 2015 Enterprise RC to Visual Studio 2015 Enterprise automatically and now those extensions that had started recently to not install, are installing fine. That way you’ll avoid the trouble of reinstalling everything.
Note that after installation finishes it shows a button to Launch Visual Studio, which will launch the Enterprise edition (or Professional in the case I guess one had Professional RC installed). However your Windows taskbar shortcuts for Visual Studio 2015 and Blend 2015 will be now broken and you have to fix them by right-clicking them and selecting Properties, then setting them to C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe and C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\blend.exe respectively, assuming you use an 64-bit OS – else remove the “ (x86)” part – and had installed Visual Studio on C: disk. You may wish to also add those links to the Start menu, under the respective folder (named Visual Studio 2015) if you also miss them from there.
Fix: Java ServletException: IncompatibleClassChangeError
was getting an error like the following at your JavaEE Servlet (Portlets are also Servlets under the hood btw):
javax.servlet.ServletException: javax.portlet.PortletException: java.lang.Throwable: java.lang.IncompatibleClassChangeError: : incorrect call to interface method
at first I thought the issue was with:
<bean:message class=”someCSSstyleClass” key="someMsgKey"/>
and used instead:
<span class="someCSSstyleClass"><bean:message key="someMsgKey"/></span>
in case the “class” attribute at bean:message tag was meaning a Java class instead of a CSS class
But, kept on getting the same error…
Then I tried a “Clean and Build” instead of just “Build” action at NetBeans IDE and errors poped up. Had refactored an abstract class to an interface and seems NetBeans was only compiling parts of my code which can cause tricky to debug errors.
So whenever you see strange runtime errors, especially when refactoring some older project, make sure you use “Clean and Build” (sometimes called “Rebuild”) in your IDE to be safe.
Fix: The tag ‘TimeUpDown’ does not exist in XML namespace (Silverlight Toolkit)
If you use TimeUpDown control from Silverlight Toolkit in your XAML like below (copy pasting from CaptionGrid at ClipFlair source):
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
<DataTemplate x:Key="StartTimeCellTemplate">
<TextBlock Margin="4" Text="{Binding Begin}" />
</DataTemplate>
<DataTemplate x:Key="StartTimeCellEditTemplate">
<input:TimeUpDown Format="hh:mm:ss"
Value="{Binding Begin, Mode=TwoWay, ValidatesOnExceptions=True, NotifyOnValidationError=true}"
/>
</DataTemplate>
…
</ResourceDictionary>
then even though it seems to not complain in the XAML designer of Visual Studio 2010, then at Build time, even if you’ve added a reference to System.Windows.Controls.Input.Toolkit assembly (the 5.0.5.0 version for the Silverlight 5 Toolkit [December 2011 release]), you get:
The tag ‘TimeUpDown’ does not exist in XML namespace ‘clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Input.Toolkit’
Similar bad behaviour occurs if you try to drag-drop the TimeUpDown control from Visual Studio toolbar (assuming you’ve installed the Silverlight Toolkit first) onto the XAML designer, no xml namespace (named xmlns:input above) is added and you just get <TimeUpDown /> in the designer.
The solution is to also add to your project a reference to System.Windows.Controls assembly (be sure to select same version DLL as above [e.g. 5.0.5.0]). For some reason the System.Windows.Controls.Input.Toolkit doesn’t seem to pull that together and must have some internal dependency to it (although the error you get is very cryptic).
Below is the Add Reference dialog of Visual Studio 2010, you either use the “Extensions” from the right handside, or type-in “System.Windows.Controls” at the search box to quickly spot those two assemblies.
Note that If you have a Silverlight assembly project with some UserControl in it and you apply the workaround I mentioned above, then if you use that UserControl in a Silverlight app (in a Page or other UserControl) you get a RUNTIME error this time at launch saying XamlParserError at the title bar and the exception text:
The type ‘TimeUpDown’ was not found because ‘clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Input.Toolkit’ is an unknown namespace
This time the fix is to add a reference to "System.Windows.Controls.Input.Toolkit" to the project.
The funny thing is that this project (that uses a library that hosts a control that uses TimeUpDown itself) DOESN’T NEED to have a reference to "System.Windows.Controls", as the library does need to compile.
The other funny thing is that it does compile OK without adding the "System.Windows.Controls.Input.Toolkit" reference, but it shows runtime error.
This issue has been reported for some time now at:
but hasn’t yet been fixed.
Update:
This may also be related:
https://zoomicon.wordpress.com/2012/07/02/fix-the-tag-xxx-does-not-exist-in-xml-namespace-clr-namespaceyyy/
I noticed that when I tried to compile on a machine that didn’t have Silverlight 5 Toolkit, it was eventually trying to use the Silverlight 4 Toolkit version of System.Windows.Control.Input from my Debug folder (not sure how that DLL ended up there, probably was brought in automatically via some other library’s dependencies by Visual Studio). So maybe you end up with multiple assemblies with the same name in the project and you have to remove the old ones.
You may also run into this issue if your solution was using Silverlight 5 Toolkit and you try to build the project on another machine that has Silverlight 4 Toolkit only. Solution is to install Silverlight 5 Toolkit too and then make sure the project refers to the 5.0 version of System.Windows.Controls.Input.Toolkit.dll and that the reference doesn’t have a path that points into your solution but to the program files folder instead, where Silverlight Toolkit gets installed.
How to crash Visual Studio 2010 via (Silverlight) XAML recursion bug
Following up on a note about Visual Studio 2010 crashing at my previous post, this is the XAML that crashes VS2010 when opened up in a Silverlight project:
<UserControl x:Class="SilverlightApplication1.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
d:DesignHeight="300" d:DesignWidth="400"><UserControl.Resources>
<ResourceDictionary>
<Style x:Key="MyStyle" TargetType="StackPanel">
<Setter Property="Margin" Value="0,5,0,5" />
</Style>
</ResourceDictionary>
</UserControl.Resources><Grid x:Name="LayoutRoot" Background="White">
<Grid.Resources>
<Style TargetType="StackPanel">
<Setter Property="Style" Value="{StaticResource MyStyle}" /> <!– THIS LINE CRASHES VISUAL STUDIO (EVEN WHEN YOU TRY TO TYPE IT IN) –>
</Style>
</Grid.Resources><StackPanel/>
</Grid>
</UserControl>
This crashes VS2010 upon loading, because it tries to show the XAML page in the designer. I created that XAML in Notepad++ since when I was trying to type the problematic line (marked in the XAML above) it crashed VS2010 immediately before I managed to save.
BTW, you should use the XAML syntax I suggested at my previous post that uses Style inheritance instead (although it would be nice if you could do for any node <X CloneSource=…/> for any XAML node to copy its attributes and values from a same-typed node instance in some resource etc. instead of relying on the node supporting some mechanism like Style does with BasedOn [that is Style Inheritance]).
<Grid.Resources>
<Style TargetType="StackPanel" BasedOn="{StaticResource MyStyle}" />
</Grid.Resources>
Speaking of crashes, VS2010 should be more clever and if it sees a certain file caused a crash (assuming it has info on file being loaded upon or just before crash), the next time of opening the solution it should warn the user against opening that file (to avoid a new crash that stops one from loading the solution).
Note that I tried to open up the XAML file standalone in Visual Studio and it says:
Style object is not allowed to affect the Style property of the object to which it applies.
at System.Windows.Setter.Seal()
at System.Windows.SetterBaseCollection.Seal()
at System.Windows.Style.Seal()
at System.Windows.StyleHelper.UpdateStyleCache(FrameworkElement fe, FrameworkContentElement fce, Style oldStyle, Style newStyle, Style& styleCache)
at System.Windows.FrameworkElement.OnStyleChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
at System.Windows.FrameworkElement.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
at System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
at System.Windows.DependencyObject.InvalidateProperty(DependencyProperty dp)
at System.Windows.FrameworkElement.UpdateStyleProperty()
at System.Windows.TreeWalkHelper.InvalidateOnTreeChange(FrameworkElement fe, FrameworkContentElement fce, DependencyObject parent, Boolean isAddOperation)
at System.Windows.FrameworkElement.ChangeLogicalParent(DependencyObject newParent)
at System.Windows.FrameworkElement.AddLogicalChild(Object child)
at System.Windows.Controls.UIElementCollection.AddInternal(UIElement element)
at System.Windows.Controls.UIElementCollection.Add(UIElement element)
at System.Windows.Controls.UIElementCollection.System.Collections.IList.Add(Object value)
at Microsoft.Expression.DesignModel.InstanceBuilders.ClrObjectInstanceBuilder.InstantiateChildren(IInstanceBuilderContext context, ViewNode viewNode, DocumentCompositeNode compositeNode, Boolean isNewInstance)
Probably it loads it into an implicit WPF project. So is this some issue with Silverlight 5 XAML loading only? And if so isn’t this a potential exploit against Silverlight apps/plugin (if they allow XAML to be passed to them that is)?
It would be interesting to fix the test solution manually to not try to load the XAML file at startup, then build it and run it to see if it crashes the Silverlight plugin, the web browser, or whatever other side-effects it causes that might be exploitable.
This issue has been submitted to Microsoft at https://connect.microsoft.com/VisualStudio/feedback/details/753211/xaml-editor-window-fails-with-catastrophic-failure-when-a-style-tries-to-set-style-property. I have attached a test Silverlight project there (should be available for download soon [takes a while] from issue details)
YouTube (Google) 502 error page
Windows 7 Command Line Help mistake for IF command
If you type
help IF
at the Windows 7 command-line (can launch this by searching at Windows Start menu search box for “Command” or by typing cmd there and pressing ENTER), you get in one of the help pages printed out for the batch files’ IF command:
%ERRORLEVEL% will expand into a string representation of
the current value of ERRORLEVEL, provided that there is not already
an environment variable with the name ERRORLEVEL, in which case you
will get its value instead. After running a program, the following
illustrates ERRORLEVEL use:goto answer%ERRORLEVEL%
:answer0
echo Program had return code 0
:answer1
echo Program had return code 1
If a program you launched from the batch file returns error code 0 (meaning usually no error), then you jump to label (using “goto” command) answer%ERRORLEVEL% that is answer0 (labels are prefixed with : in DOS/Windows batch files) and it prints out (using echo command) on the console “Program had return code 0”.
Fine till here, but then it will proceed to next commands (the block labeled :answer1) and also print out “Program had return code 1”. Obviously the correct example should be:
goto answer%ERRORLEVEL%
:answer0
echo Program had return code 0
goto finish
:answer1
echo Program had return code 1
:finish
Could also have a goto finish after the last echo, but its needless since we don’t have :answer2 etc. labels after that and proceeds to finish by itself anyway.
Thinking of this example again, it’s a pretty silly one since one could do instead:
echo Program had return code %ERRORLEVEL%
BTW, to output an empty line to the console you can use echo:
And speaking of batch file tips, you can use :: for comment lines instead of REM command.
Η σελίδα σφάλματος του YouTube
500 Internal Server Error
Λυπούμαστε, κάτι δεν πήγε καλά.
Η διευθέτηση του ζητήματος έχει ανατεθεί σε μια άρτια εκπαιδευμένη ομάδα μαϊμούδων.
If you see them, show them this information:
IH6pYV6uW08aEw7RTmh2nctOCLKwYBoSQTT250UKk1Aq9OGTSu0MO16kB8kH IX8I1EZVDq2NHuva2SRpXGL6hG38xdffPCV3YBYJu8LVe1L9r7vz_fQrTavV aEsYIAILDGIATDB2OC78kZeqDUS9jeQzQqBiA6_Q7RDGkivkzT6XcaChvBAI TVWzwDPaNPJV8J7m2aqxgprbkCwzzcIfMD1toWoe4cbls7NqoBvCYAEsfZKD HlQ_3ylykRbFkJfi1HapcCFYJvnFB-6wyNYtgciyVuTEcieOHUq3-6zSAHk9 jzA1y2nndSZdSonvl5QTyCxWlrUzJR-ILxQuCmLI7iJgjl6r6rJCiR0G4ETR 4saaalM-MS2GGaikabqbENBLmtcerB5ZM37s-CgMgfbgxjTDb6__Te4_hveU H0mFIVTykRF3KkJKNTbKnXgzZ8l3OxU1KFiPL3Qsbnk5XADrMx1ThvgRWS-C wANkQ3C7EM0TDm0Xfwl4lVg2tE_eGmdktkmSzIpK3mnzZMUJ5TPhpchuoE_H kSIcV16f_p2phAfJsjbwKs11szwt_HLlEyeH1MUizpvNcrMh8qzDcd2H8siN mtkBjG0NrRjPyh2Cv8VIxfY__LpSJQ5J-V8t7ee9wFgmRrwL0MbzOopueiV_ SccnIpDai8vLFWAnAUr_AsNKKmHMd8BMEb2tiPinyoZUspbc1ad8cmn0_QUm EeXVbx0G3pSdnESz-5zD0gg2xCmtJg3xKIaYSF5rKAGS5nnDLoneX3D5SPoQ aIpRDo_-edF48zLYG5hmI2QSrUKiIuZreHmdw7YELfs5J6JJcWHDXfFTrHaY Irm6IGuf8-P9XmgbaRbSH8Do-p2Q5-Jpr2ZlzcESPusTn2ZG-qu6Ootp3g9n v0tNtWeV9FJN9_BPUNuQUZ8OzFwR3m92UuFQbP91wrhTcf3GI8aO8aQInR0H OjVNyUM_xfy7LVcaZM3wE7Q109fIa0wjoOT5-YgwM39YqFp850lCdCCGQ_6E L_0YPv_J0x9ICvFRS1H00CpkAE4umSnqMgIXNyGQvXLCEyVR-sgNlZmSdgK1 CWSmjq7FQAB2g-6xiBHYpFLCSn3GQiaZDdhBw1hSKpqwcbl-WpjP8Dr9_eiP 52HOndQj2dIYwsyqk7NpFWY7yqneAYApZfr062sC9UggAFfW3f3hW0LalNvp 6gtogSkhpkx_ZgTkbqg3AVZT7VdEJ0cD_MFGBwIQ93HfTJKXVfXvDPPw70H4 WlyvuHFB9x7PR-ZWwftrR_PDsgKL31aVnR5VB328YalCHZbcX6vCv2Sg7X2N mCo1TwAOx0tPf0R85Z0_PjqhkhQp91xEMZlDEHDZ0QAPyDaR1Ud4mnMcKf5v UjMxY0D4HNknezAOa7iUYzySU_dUinT9U9YC1bSSFEcAkDluIi_BP-z8nyzb 2UYfOJrbVa6kFmNbno3cK5xYQk7VxBp2SDTowexy0MVxuCPF9sWye8vkHKXx WoQUgJ8xM7t0-uUfv4OUWVo4NVh7YTUZAbMrnSI1B17nJseXYBO7KeJxARIs ZpmsKLDQgi-OPhdICGl_VQ1u5MW3DWGdKCzplSHJVS_aqHM0hXjHVMOjWhdU 3bbV82b7QLMwzVsain7gq__Xu3ELz9b6LwyIGWuEWHQ_JXRqC28GHNP3DQuE _rBbjRhz2rT8TsCz0-ytw51mwMj8GMDXlPrWe_rIRmGeTZycjdnSMtpMKsAI EHzXZV4it2ueblqufGfNsq85haQgLJ6h7z0OlNgAaUDIlvatUwNZ1bFd8FlG 7p9R5tCv5zHNCZlgm4ckrZnPrLmMoeevZOIpT_DHBc_BDufz377CQIXV296Z f_UKhYgval991AmqBIr6z_Pn_5YBnMW-ab1Ofs_TknLGQRDEw0GIBIjDoYpY oYvVcnS6X16jg4zajlfRJUITSrljGQWjbg0O12acB-P_SzcLZBUo5toKKvqw aXTQO64PXrkqI0qB1olJEJ9dCzwOWvRTy8EUxUpzdUwTcfVsanwyLh4iHbND JNVXUUELdi6-ufbhaRbge7x9KDMywHHayq9E6oQQNQIZ9aU_crS6x0JJDtxQ Vu0Go2XSmQWM1-1o-IkXZDnhqPBJMSYgnePeg5op-q50vPpdUZtYZsuCkytU MX6zEqe5SQU7wRL7xAyCLnMG4q-5oykERg7wYBdbk5GJ6bLtzNof24zBrCMH H-L0pBSrFagcz9HlAvQ2PjmQMOc1Bh-ymOBs9iJt2NyCfcZcG9AOb9KzDto1 VUavWLVDWfcmmxcwOjuQjQwGz2Riqpa-mxCADuFe6ISTv2MJ2dLqMK19Byho 95fo66KT_cLl0jxm70z-NLsunBmlIW5O9zjZv5uySrptMIIFQUOPS2xFBBqT VRrEAg9vpsEYx8h9H2xjOjHVdOpsoCDi4CkSKLmczZ-IMzvx6eajUWuaZMT5 01a-vSK_dis7lHtI_2UWydC_eZN2HGRP-4meXByQ8AupsSoWrz0eUhdIMFSe uQzEPRMOrMJ7yBxobSFYnubs6CRNWwxiV7r6HT_RIjaql6j6wvCBSWtT6Ko3 Gz7hoShAjBRMwNROLUMtFt1VrDbH5VvmZ8UEPNbeY4hyNLIQOWyA3gcgHtZZ Zl3_H72IAed12gK9S_R7zEj7Dxb66vfLUDlE8yK7a50lO4BdOgS4tPZcY9TU cA5iWzHiPVtXcvr9dga8K3dHm6a75vzyfFDU2DcB630PPWBu8IJoGUdVZKRF TrcmQkH4W4rXLT2rixMaNDkLCPIZxHzpo9raSYsLayElyLLeJciCvguqtbfv CpmGFuRYAxoFH49-_LO3vl4DSSGENleRoxAUpAIevoBl4KCpTacEZ9xHLMLw IHFYr1Unj3GWZiAidjQaSFD8Me4uGM7tXbYt_RJUAhFb9O-xmHIrOHgWNhsh icxG8rAH-kkgycoDF5tYlv-4UTsQtkffgWGK8PltToYgDfSfL_b0ah42qg==