"Win32Exception (0x80004005): Not enough storage is available to process this command" is thrown when multiple RadDocument instances are created in background threads. 

This is due to the fact that RadDocument contains MailMergeDataSource object, which is DependencyObject. When multiple dependency objects are created in different threads, they are not property freed by thread's Dispatcher.

Workaround 1: Microsoft provided workaround in a bug report here:
https://connect.microsoft.com/VisualStudio/feedback/details/620588/system-componentmodel-win32exception-0x80004005-not-enough-storage-is-available-to-process-this-command , namely:
------------------------------
Put the following code:

Dispatcher dispatcher = Dispatcher.CurrentDispatcher;
dispatcher.BeginInvokeShutdown(DispatcherPriority.Normal);
Dispatcher.Run();

anywhere in the background thread processing the RadDocument.
-----------------------------

Workaround 2: Use pooling of the used threads. The problem is that Task Parallel Library (which has built-in pooling) does not use STA threads by default, but this can be achieved by using custom TaskScheduler (attached, the code is get from here: https://code.msdn.microsoft.com/ParExtSamples ):

            var parallelOptions = new ParallelOptions()
            {
                TaskScheduler = new StaTaskScheduler(Environment.ProcessorCount)
            };

            Parallel.For(0, 10000, parallelOptions, cc =>
            {
                    var document = new DocxFormatProvider().Import(data);
                    byte[] pdfBytes = new PdfFormatProvider().Export(document);

            };

Exporting documents that contain PNG images SMask and ImagesDeflaterCompressionLevel is set to a non-default value may produce a document in which those images are not processed correctly by Adobe reader.

On export to HTML tab stops are converted to non-breaking spaces ( ). Sometimes the width of the all nbsp-s becomes different than the width of the tab stop. When document which contains grid-like data is exported to HTML its columns are not aligned.

The content of the cell is set from .LoadContent() method and is returned from the CreateCellElement method of the column. 

One possible scenario for a fix is to change that behavior and apply directly the template as WPF DataGrid does. However, this is a huge breaking change with CreateCellElement method is widely used. The second approach is to leave the code as it is right now, return the element from method of DataTemplate and set the ContentTemplate property of the cell to that DataTemplate. This will cause the content to be loaded twice. Which will degrade the  

So, as it turns out the solution is either to introduce breaking change or degrade the performance. Both of them are against our believes and efforts to improve the controls. 

Our suggestion is to use a workaround -  setting triggers directly to the style. We do hope you understand our concerns. 

The fix for this issue will be available with the next LIB (version 2018.3.1224) expected on Monday, December 24.

This behavior is reproducible when we have applied Material theme and we have disabled the selection and drag of a RadTreeViewItem. 
A possible workaround is to set the MaterialAssist.CheckedBrush attached property to Null of the RadTreeViewItem which you don't want to select and drag.

 xmlns:material="clr-namespace:Telerik.Windows.Controls.MaterialControls;assembly=Telerik.Windows.Controls"

 <telerik:RadTreeViewItem Header="RootItem" material:MaterialAssist.CheckedBrush="{x:Null}" />

The Expression property of the PropertyNameMetadata is used as a base for a Regex that is run against the property names of the object that is being serialized. Therefore, you should consider it a regex expression and set its value as in the following example:
- to match only the property "Width" - use the expression "^\b(Width)\b$", without the quotes.
- to match the "Width", "MinWidth" and "MaxWidth" - use the expression "Width", without the quotes.

Multiple operations applied on a big RadBitmap can cause OutOfMemoryException because of used and not disposed unmanaged resources in a WriteableBitmap object.

Steps to reproduce:
- Execute multiple times the Rotate tool
Observe: The memory goes up and retains such.
Expected: The unmanaged memory is cleared.

Findings: the memory leak is related to the WPF class WriteableBitmap which is internally used by the RadBitmap. Attached is a sample project illustrating the problem using only WPF classes.
Note: At this point, we are not aware of a possible fix.

When using an ItemContainerStyle on the second(non-root) BarItems, the Background doesn`t apply

When the properties are bound in code behind, they are not updated as they are supposed to.

Binding them in XAML, by setting the DataContext of the control as StaticResource, works as expected.

The vertical scrollbar measure incorrectly when the control's ItemsSource is populated in its Loaded event. To reproduce this, set the ItemsSource when the control is initialized. And then populate it on Loaded. Also, to reproduce this you will need to define the columns manually.

To resolve this, populate the data on initialization of the gridview. Or delay the population to happen after the Loaded event. You can use a dispatcher for this.

For the time being, an appropriate converter should be used for the bindings.

When the slider is placed inside a ScrollViewer and the scrollviewer is resized fast a "Layout cycle exception is thrown".

The original scenario where we reproduce the exception is the following:
SelectionStart, SelectionEnd, Minimum and Maximum of the Slider are bound to DateTime.Ticks via converter.
Exception is not reproduced if you move the Mininum declaration in xaml before the Maximum. And same for SelectionStart = before SelectionEnd.

We are closing this item due to the workaround and the fact that it is NOT reproducible in WPF.

If your scenario is different, please open a new support thread with more information regarding this exception.

In a two monitors scenario the ApplicationMenu appears on the left monitor when the RibbonView with negative left margin is hosted in a RibbonWindow which is maximized on the right monitor.

EDIT:
We are closing this issue as the described behavior as expected. When logged first, the negative left margin of RibbonView was not taken into account.
When popup opens and its parent starts on the left monitor, popup calculates that it cannot fit entirely and changes its direction of opening. This expected by the WPF Framework.
When you give negative left margin of the RibbonView, its application button might also goes with 1-2 (or more) pixels on the left monitor. Then popup (the application menu opens in a popup) has no space and changes its opening direction to left.
This is expected and the only reasonable solution would be changing the negative left margin to positive or 0.