Service delay for both Azure and Onpremise

Indication of error in the api and causing a delay in the service for both Azure and On Premise.
It does not find all those modules in the requests.
Performing a memory dump to the service with the Azure diagnostic tools, the following was found.
Memory usage is huge and almost all Worker threads are waiting for memory allocation.
GC Allocated Heap Size: Size: 0x1357caea0 (5192330912) bytes. //5.1 GB
GC Committed Heap Size: Size: 0x1372b1000 (5220536320) bytes. //5.2 GB
Example of the awaiting memory allocation calls:

000000CCA2BFF1C0 00007ffa105e4d6f KERNELBASE!WaitForMultipleObjectsEx + 0xef [d:\rs1\minkernel\kernelbase\synch.c:1551], calling ntdll!ZwWaitForMultipleObjects [d:\rs1.obj.amd64fre\minkernel\ntdll\daytona\objfre\amd64\usrstubs.asm:907]

000000CCA2BFF1E0 00007ffa13266547 ntdll!RtlFreeHeap + 0x437 [d:\rs1\minkernel\ntos\rtl\heappublic.c:333], calling ntdll!RtlpInterlockedPushEntrySList [d:\rs1\minkernel\ntos\rtl\amd64\slist.asm:229]

000000CCA2BFF260 00007ffa105e4e73 KERNELBASE!WaitForMultipleObjectsEx + 0x1f3 [d:\rs1\minkernel\kernelbase\synch.c:1503], calling ntdll!RtlActivateActivationContextUnsafeFast [d:\rs1\minkernel\ntdll\sxsctxact.c:576]

000000CCA2BFF2B0 00007ffa0c7fffa1 WindowsCodecs!GetWicPixelFormatSize + 0x19 [d:\rs1\onecoreuap\windows\wgi\wic\base\pixelformatinfo.cpp:768], calling WindowsCodecs!CPixelFormatInfo::GetBuiltinComponentInfo [d:\rs1\onecoreuap\windows\wgi\wic\base\pixelformatinfo.cpp:817]

000000CCA2BFF2F0 00007ff9f77a786d coreclr!SVR::gc_heap::allocate_soh + 0x2ad [D:\a_work\1\s\src\coreclr\gc\gc.cpp:17117], calling coreclr!SVR::gc_heap::a_fit_segment_end_p [D:\a_work\1\s\src\coreclr\gc\gc.cpp:16716]

000000CCA2BFF350 00007ffa13199dac msvcrt!free + 0x1c [d:\rs1\minkernel\crts\crtw32\heap\free.c:183], calling ntdll!RtlFreeHeap [d:\rs1\minkernel\ntos\rtl\heappublic.c:316]

000000CCA2BFF380 00007ffa0c7e8f28 WindowsCodecs!CCodecFactory::Release + 0x48 [d:\rs1\onecoreuap\windows\wgi\wic\base\ccodecfactory.cpp:458], calling WindowsCodecs!operator delete [d:\rs1\minkernel\crts\crtw32\linkopts\nothrownew.cpp:97]

000000CCA2BFF390 00007ff9f77a71f9 coreclr!SVR::gc_heap::balance_heaps + 0x35 [D:\a_work\1\s\src\coreclr\gc\gc.cpp:18124], calling ntdll!RtlGetCurrentProcessorNumberEx [d:\rs1\minkernel\ntdll\amd64\procnuma.asm:107]

000000CCA2BFF3D0 00007ff9f7841ec2 coreclr!SVR::gc_heap::try_allocate_more_space + 0x9d116 [D:\a_work\1\s\src\coreclr\gc\gc.cpp:18072], calling coreclr!SVR::gc_heap::allocate_soh [D:\a_work\1\s\src\coreclr\gc\gc.cpp:17065]

000000CCA2BFF430 00007ff9f77a520c coreclr!SVR::gc_heap::allocate_more_space + 0x5c [D:\a_work\1\s\src\coreclr\gc\gc.cpp:18547], calling coreclr!SVR::gc_heap::try_allocate_more_space [D:\a_work\1\s\src\coreclr\gc\gc.cpp:17955]

000000CCA2BFF480 00007ff9f77a7077 coreclr!SVR::GCHeap::Alloc + 0xb7 [D:\a_work\1\s\src\coreclr\gc\gc.cpp:46338], calling coreclr!SVR::gc_heap::allocate_more_space [D:\a_work\1\s\src\coreclr\gc\gc.cpp:18509]

000000CCA2BFF4C0 00007ff9f7765adc coreclr!Thread::DoAppropriateWaitWorker + 0x184 [D:\a_work\1\s\src\coreclr\vm\threads.cpp:3514], calling kernel32!WaitForMultipleObjectsEx

Top items in managed heaps:

7ff99968ac98 1,395,569 33,493,656

??
7ff999c29da8 1,395,895 44,668,640 System.Collections.Generic.List???>
7ff997d0bf38 584,482 49,967,272 System.Int32[]
7ff999642368 1,072,008 51,456,384 [1]???
7ff9999ce400 2,519,888 60,477,312
???
7ff999783b58 1,068,228 68,366,592 ??
7ff999c25240 223,959 73,727,184 [1]???<

??>+

[]
7ff999c2a040 1,395,850 78,232,528???[]
7ff99a362520 126,560 82,573,320 [1]???[]
7ff99976b738 2,919,934 93,437,888 ???
7ff99a2dbcf8 2,222,052 106,658,496 System.Collections.Generic.SortedSet<System.Collections.Generic.KeyValuePair<System.Int32, System.Int32>>+Node
7ff9996421a0 4,275,943 136,830,176

??
01ec53178af0 157,656 144,781,592 Free
7ff9999ce520 2,519,888 161,272,832
???+[1]
7ff9995792e0 2,462,292 295,475,040 [1]??
7ff997e8d288 94,718 371,664,848 System.Char[]
7ff999bc2430 1,571 476,904,040 [1]???+

[]
7ff997e38688 16,137 507,546,177 System.Byte[]
7ff99956f908 19,678,276 629,704,832 [1]???+

7ff997d0fd10 3,425,577 1,073,895,806 System.String
Total 58,564,450 objects, 5,188,425,648 bytes
As you can see, there are several types that cannot be displayed. I can’t check those objects in the debugging tool, they are some very special ones. I think it is related to System.Drawing and GDI+. These are not compatible with ASP.Net or ASP.Net Core applications.

See unsupported modules loaded below:

start end module name
00007ff9de880000 00007ff9dea1a000 GdiPlus (private pdb symbols) C:\ProgramData\Dbg\sym\gdiplus.pdb\E0F1D340D7BF4C49A256902D258123581\gdiplus.pdb
Loaded symbol image file: GdiPlus.dll
Image path: C:\Windows\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.14393.5501_none_aec664b1ddd8c519\GdiPlus.dll
Image name: GdiPlus.dll
Browse all global symbols functions data
Timestamp: Thu Nov 3 21:34:32 2022 (63647A38)
CheckSum: 001A18CA
ImageSize: 0019A000
File version: 6.2.14393.5501
Product version: 10.0.14393.5501
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
Information from resource tables:
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: gdiplus
OriginalFilename: gdiplus
ProductVersion: 10.0.14393.5501
FileVersion: 10.0.14393.5501 (rs1_release.221103-1703)
FileDescription: Microsoft GDI+
LegalCopyright: © Microsoft Corporation. All rights reserved.

start end module name
000001fb7da90000 000001fb7db2a000 System_Drawing_Common (deferred)
Image path: C:\home\site\wwwroot\runtimes\win\lib\net7.0\System.Drawing.Common.dll
Image name: System.Drawing.Common.dll
Browse all global symbols functions data
Using CLR debugging support for all symbols
Has CLR image header, track-debug-data flag not set
Image was built with /Brepro flag.
Timestamp: D710BCD7 (This is a reproducible build file hash, not a timestamp)
CheckSum: 00099A27
ImageSize: 0009A000
File version: 7.0.22.51805
Product version: 7.0.0.0
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0000.04b0
Information from resource tables:
CompanyName: Microsoft Corporation
ProductName: Microsoft® .NET
InternalName: System.Drawing.Common.dll
OriginalFilename: System.Drawing.Common.dll
ProductVersion: 7.0.0+d099f075e45d2aa6007a22b71b45a08758559f80
FileVersion: 7.0.22.51805
FileDescription: System.Drawing.Common
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Provides access to GDI+ graphics functionality.
It is attributed that the Aspose.Drawing and/or Aspose.Drawing.Imaging refer to the libraries that the memory dump throws.

@BoomslangTech2023,

Could you please elaborate your issue and provide more details about your issue. What tasks you are performing using Aspose.Drawing or Aspose.Drawing.Imaging and when you get the issue? Moreover, please provide us a sample project with resource files to reproduce the issue on our end. We will check your issue soon.

In general, the problem we have is high times in the conversion from HTML to PDF and high memory consumption that is causing unavailability in the services where the Aspose.Total for .NET libraries are used.

@BoomslangTech2023,

Do you use Aspose.Words or Aspose.PDF API for it? Please provide sample files (input file(s)) and sample project/code to reproduce the issue.

As requested earlier, please provide us a sample project with resource files to demonstrate the issue on our end. We will check your issue soon.

IMAGEN 1.png (5,0 KB)
IMAGEN 2.png (2,7 KB)
IMAGEN.png (62,4 KB)

I request the information and share shortly

@BoomslangTech2023,

Thanks for the screenshots.

We are looking forward to get sample projects and sample files (as requested) for your issue(s). Please take your time and provide the required materials.

Our team Aspose.Barcode huge number of memory leaks with System.Drawing.Common on non-Windows platforms. We replaced it to Aspose.Drawing.Common and it have fixed issue.

At least Aspose.PDF uses System.Drawing.Common and it can be problem.

Aspose.Drawing.Common solves memory leaks and glitches in .Net Core (tested up to .Net 7) because it was written on pure C# without any external libraries access.

In this way, you should open issues on forums (Aspose.Words uses Skia.Sharp) to avoid using System.Drawing.Common:

  • Aspose.PDF
  • Aspose.Cells
  • Aspose.Imaging
  • Aspose.HTML

A post was split to a new topic: High times in the conversion from HTML to PDF and high memory consumption that is causing unavailability in the services (Azure and on-premise)