Develop Reference

Issue with providing load balancing information using AxMSTSCLib

I am trying to establish a remote desktop connection via a remote desktop session broker in my C# application using the 'AxInterop.MSTSCLib' where I encounter problems with the transfer of the load balancing information.
Basically, I create a new object and set the basic parameters. A connection directly to a single Remote Desktop (RD) server is already possible with this:
var rd = new AxMsRdpClient11NotSafeForScripting();
rd.Server = "target-server.domain.local";
rd.UserName = "user";
var secured = (MSTSCLib.IMsTscNonScriptable)rd.GetOcx();
secured.ClearTextPassword = "password";
The RD environment I want to connect to consists of multiple RD service collections, each managing one or more RD Servers. For new RD connections, RD clients connect to an RD broker server, which redirects the clients according to the individual load balancing information they provide.
To provide this load balancing info, using mstsc.exe and a .rdp file I provide the setting 'loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.99999' where '99999' is the name of the targeted RD Collection which works fine. To implement this in MSTSCLib, I have to set it with 'rd.AdvancedSettings9.LoadBalanceInfo'.
However, as this post on the Microsoft Technet forum also describes, the load balancing info string must first be re-encoded.
var lbinfo = "loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.99999";
if (lbinfo.Length % 2 == 1) lbinfo += " ";
lbinfo += "\r\n";
var b = Encoding.UTF8.GetBytes(lbinfo);
var final = Encoding.Unicode.GetString(b);
rd.AdvancedSettings9.LoadBalanceInfo = final;
According to the last comment in the Technet post, the number of bytes must be even, so a space (U+0020) is added if necessary.
With 'rd.Connect()' the connection is established and my client reaches the connection broker. In the first step, my connection request appears in the logs of the broker server:
[TerminalServices-SessionBroker (Operational)]
The Remote Desktop Connection Broker has received a connection request for user {user}.
Notes in the RDP file (TSV URL) = 'tsv://MS Terminal Services Plugin.1.99999 '
(note: there are two empty spaces at the end of the string)
Original application = NULL
The call comes from the redirection server = broker.domain.local
The redirector is configured as a virtual machine redirector.
Note the two spaces at the end of the TSV URL that gets added by the used code because the bytes count would be uneven otherwise. The only difference to mstsc.exe is that there is only one space (which is the new line break we also add I guess) displayed.
In the next step, the error occurs and our connection attempt fails. It says 'The farm specified for the connection does not exist.'
The OnDisconnected event is triggered and provides me the information: 'DiscReason: 3' and 'ExtendedDisconnectReason: 1040'.
My guess: Because of the space we add, the name of the RD collection can't be assigned correctly anymore. If we compare the passed information (loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.99999) on byte level, we also see that this added space is the only difference:
mstsc.exe
74 73 76 3a 2f 2f 4d 53 20 54 65 72 6d 69 6e 61 6c 20 53 65 72 76 69 63 65 73 20 50 6c 75 67 69 6e 2e 31 2e 39 39 39 39 39 0d 0a
AxMSTSCLib:
74 73 76 3a 2f 2f 4d 53 20 54 65 72 6d 69 6e 61 6c 20 53 65 72 76 69 63 65 73 20 50 6c 75 67 69 6e 2e 31 2e 39 39 39 39 39 20 0d 0a
Note the third last byte, the U+0020, which we added to achieve an even byte count.
If I do not add the space and the number of bytes (43) is thus not even, I see in WireShark that the TPKT packet is not even sent anymore. The broker server, according to its logs, also takes no notice of the connection attempt. The OnDisconnected event provides me the information:: 'DiscReason: 4' and 'ExtendedDisconnectReason: exDiscReasonNoInfo'. So it seems that the AxMSTSCLib already assumes that the byte number is even.
Unfortunately, I can't figure out how mstsc.exe manages to successfully transmit the same odd string. On the byte level, I work supposedly identically.
I have uploaded the entire byte contents of the TPKT packages here for better comparison: https://pastebin.com/tLtfWHiP
I am grateful for any ideas.
Thanks and regards
Lukas P.

I tried a lot before I came up with a solution: adding space, zero width space chars like \u200B, before the load balancing string, and behind it. But the rd broker didn't take it.
Solution:
In case of an odd number of bytes, if we put a dot (U+002E) in the right place, the rd session broker can extract the required identifier for the targeted rd collection and the connection will be established correctly.
private void RdpLogic()
{
AdvancedSettings9.LoadBalanceInfo = ToLoadBalanceString($"tsv://MS Terminal Services Plugin.1.lbinfo");
}
private string ToLoadBalanceString(string loadBalanceInfo)
{
var temp = loadBalanceInfo;
if (temp.Length % 2 == 1) temp = temp.Insert(temp.LastIndexOf('.'), ".");
var final = Encoding.Unicode.GetString(Encoding.UTF8.GetBytes(temp + "\r\n"));
return final;
}
Samples:
ToLoadBalanceString("tsv://MS Terminal Services Plugin.1.even")
Result: 'tsv://MS Terminal Services Plugin.1.even/r/n'
ToLoadBalanceString("tsv://MS Terminal Services Plugin.1.odd")
Results in 'tsv://MS Terminal Services Plugin.1..odd/r/n'

C# Renci SshNet The server response contains a null character at position 0x0000002A

i have multiple Raspberries running with SSH server:
(OpenSSH_7.4p1 Raspbian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019).
And if i try to connect via Renci SshNet, i get the following error message:
Renci.SshNet.Common.SshConnectionException: "The server response
contains a null character at position 0x0000002A:
00000000 53 53 48 2D 32 2E 30 2D 4F 70 65 6E 53 53 48 5F
SSH-2.0-OpenSSH_ 00000010 37 2E 34 70 31 20 52 61 73 70 62 69 61 6E
2D 31 7.4p1 Raspbian-1 00000020 30 2B 64 65 62 39 75 37 0A 00
0+deb9u7..
A server must not send a null character before the Protocol Version
Exchange is complete.
More information is available here:
https://www.rfc-editor.org/rfc/rfc4253#section-4.2"
SshClient scClient = new SshClient("123.123.123.123", "pi", "raspberry");
scClient.Connect();
is it possible to change the behavior of the ssh server,
or even better; can i tell renci ssh to ignore these protocol errors?

I think it's a problem of the latest SSH.NET NuGet Package. Currently the newest is 2020.0.0. And the one prior to that is 2020.0.0-beta1.
2020.0.0 gives me this problem, 2020.0.0-beta1 does not.
I will report this issue on https://github.com/sshnet/SSH.NET/issues
EDIT:
2020.0.1 just got published. That doesn't seem to have this problem. I recommend you to try that version.

What is difference between WebUtility.HtmlEncode and AntiXssEncoder.HtmlEncode?

AntiXssEncoder.HtmlEncode have support only for .Net framework.
Can I use WebUtility.HtmlEncode for Antixss as we have our application in .net core 2.1?

TL;DR:
AntiXssEncoder.HtmlEncode have support only for .Net framework. Can I use WebUtility.HtmlEncode for Antixss as we have our application in .net core 2.1?
Correct.
But I want to stress that there is no-such thing as an "anti-XSS HTML-encoder" because all correctly-implemented HTML-encoders will protect your website from XSS attacks when used correctly.
(I don't know why Microsoft named it AntiXssEncoder, but given that at-the-time the main HtmlEncode implentation was actually buggy and insecure probably might have something to do with it, but that's ancient-history now.)
In .NET Core 2.1, you only need to use System.Net.WebUtility.HtmlEncode.
In other .NET releases (especially historical versions), things are complicated, read on if you dare...
Why AntiXssEncoder (aka AntiXss and AntiXss.Encoder) exists - and why it's obsolete in 2021:
The AntiXssEncoder class from the AntiXss NuGet package (aka Microsoft.Security.Application.AntiXss) is obsolete (and has been since 2014) when it was moved to System.Web.Security.AntiXss.
The other classes: AntiXssEncoder, Encoder, and AntiXss are just alternative APIs for the same underlying implementation in Encoder btw.
The AntiXssEncoder in System.Web.Security.AntiXss is not available in .NET Core 2.1. However this is not a significant problem:
The original Microsoft.Security.Application.AntiXss was created because HttpUtility.HtmlEncode was considered insecure because it did not encode single-apostrophe characters, so XSS attacks were possible against ASP.NET 1.x and ASP.NET 2.x WebForms (.aspx) pages that used single-apostrophes to delimit HTML attributes that contained user-specified values.
For example:
String userProvidedValue = "bad.gif' onerror='alert()";
<img src='<%= this.Server.HtmlEncode( userProvidedValue ) %>' />
...which will be rendered as:
<img src='bad.gif' onerror='alert()' />
However this issue was fixed in ASP.NET 4.0 when HttpUtility.HtmlEncode was corrected to also HTML-encode those apostrophes. So the exact same code above will now be rendered as below, which won't show an alert():
<img src='bad.gif' onerror='alert()' />
AntiXssEncoder also supported specifying a list of excluded Unicode code-points or Char values, this was added because AntiXssEncoder defaulted to hex-encoding all Char values (not code-points!) above 0xFFFF, which unfortunately meant that even completely safe text in Arabic, Hebrew, Kanji, etc would be escaped, making the raw HTML almost unreadable and ballooning the output HTML length.
For example the (gibberish) string "لك أن كلا" would be rendered as "لك أن كلا" - which isn't good.
Fortunately AntiXssEncoder.MarkAsSafe can be used to exclude character ranges at the programmer's discretion.
By the time .NET Core 2.1 came out, the System.Net.WebUtility class (not to be confused with System.Web.HttpUtility, of course) was improved so that it does not unnecessarily hex-encode high Char values and it does also HTML-encode apostrophes, hence why AntiXssEncoder was no-longer needed.
In .NET Core 3.1 (and later, including .NET 5 and .NET 6) things improved further, but also got a bit confusing...
Things got better because System.Text.Encodings.Web.HtmlEncoder was added. This is a separate implementation (instead of simply wrapping WebUtility) which brings back AntiXssEncoder's ability to exclude ranges of characters from encoding just in case you need that functionality. But it's a bit of an edge-case, imo.
You can do this by calling HtmlEncoder.Create(TextEncoderSettings) with a configured TextEncoderSettings object with the required char ranges excluded.
In .NET Core 3.1, for the sake of back-compat, Microsoft brought back System.Web.HttpUtility, however this is just another wrapper over WebUtility.HtmlEncode.
It does also have HtmlAttributeEncode - which does not encode single-apostrophes. There is no good reason to use this method, imo. I'm surprised Microsoft hasn't annotated it with [Obsolete], actually.
However, in .NET Core (and .NET 5 and later) there isn't any way to HTML encode text such that named entities are used instead of hex-encoded entities (other than <, &gtl and &).
Previously, the AntiXssEncoder.HtmlEncode (both Microsoft.Security and System.Web.Security) method had a the useNamedEntities parameter which involved a large hard-coded table of known entity names, e.g. £ becomes £ instead of .
I imagine they removed this functionality because you cannot safely used named-entities unless all other software in your HTML-processing pipeline also supports it, and given it's a large table I expect that lots of people had issues with it breaking poorly-updated downstream code.
The HTML Living Standard (aka "HTML5") calls them character references instead of "entities" (a holdover from SGML DTDs) and defines the &#nnnn;-syntax as means of encoding Unicode code-points specifically as opposed to a character-value in some other encoding scheme, whereas previously in HTML4 the spec refers to ISO 10646 (aka UCS) characters which is not Unicode as we know it today. (and I suspect that browsers may have tried to map characters based on the document's encoding/code-page if the page wasn't encoded using Unicode (like Shift-JIS), but I might be wrong).
Finally, here's a table comparing the output from all of the different HtmlEncode methods found in .NET as of 2021:
HtmlEncode methods available in .NET Framework 4.8
Note that the following HtmlEncode methods are excluded because they're just wrappers over other implementations:
System.Web.HttpServerUtility (aka Server.HtmlEncode) just forwards to HttpUtility.HtmlEncode.
System.Web.UI.HtmlTextWriter.WriteEncodedText also forwards to HttpUtility.HtmlEncode.
System.Web.HttpUtility.HtmlEncode:
In ASP.NET 1.x and ASP.NET 2.0 (2001 and 2005 respectively) this is incorrectly implemented such that it does not escape apostrophes. I've included results from that implementation in the "System.Web.HttpUtility.HtmlEncode (ASP.NET 1.1 and 2.0)" column, for historical curiosity.
In ASP.NET 4.x, the HttpUtility.HtmlEncode method just forwards to System.Web.Util.HttpEncoder.Current.HtmlEncode(s)
Note that System.Web.Util.HttpEncoder.**Current** can be replaced at runtime, which is how an update to ASP.NET 4.x (I forget which) was able to make almost everyone use (the then far-better) AntiXssEncoder without people needing to change their existing application code. Neat.
Also note that System.Web.Util.HttpEncoder.**Current** can point to any compatible implementation, while System.Web.Util.HttpEncoder.**Default**`` is _always_ just a wrapper over WebUtility.HtmlEncode`.
System.Web.Util.HttpEncoder.Default - as mentioned above, this is just another System.Net.WebUtility wrapper.
#
Input
Code-point(s)
UTF-8 bytes
UTF-16 bytes
System.Net.WebUtility.HtmlEncode
System.Text.Encodings.Web.HtmlEncoder
System.Web.Security.AntiXss.AntiXssEncoder.HtmlEncode(false)
System.Web.Security.AntiXss.AntiXssEncoder.HtmlEncode(true)
0
abc
U+0061 U+0062 U+0063
61 62 63
61 00 62 00 63 00
abc
abc
abc
abc
1
<
U+003C
3C
3C 00
<
<
<
<
2
>
U+003E
3E
3E 00
>
>
>
>
3
&
U+0026
26
26 00
&
&
&
&
4
"
U+0022
22
22 00
"
"
"
"
5
'
U+0027
27
27 00
'
'
'
'
6
Ÿ
U+009F
C2 9F
9F 00
Ÿ
Ÿ
Ÿ
Ÿ
7
U+00A0
C2 A0
A0 00
 
 
 
8
ÿ
U+00FF
C3 BF
FF 00
ÿ
ÿ
ÿ
ÿ
9
ā
U+0101
C4 81
01 01
ā
ā
ā
ā
10
~
U+007E
7E
7E 00
~
~
~
~
11
| `U+007F` | `7F` | `7F 00` |



12
£
U+00A3
C2 A3
A3 00
£
£
£
£
13
ÿ
U+00FF
C3 BF
FF 00
ÿ
ÿ
ÿ
ÿ
14
Ḃ
U+1E02
E1 B8 82
02 1E
Ḃ
Ḃ
Ḃ
Ḃ
15
💩
U+1F4A9
F0 9F 92 A9
3D D8 A9 DC
💩
💩
💩
💩
16
𣎴
U+233B4
F0 A3 8E B4
4C D8 B4 DF
𣎴
𣎴
𣎴
𣎴
17
𣎴
U+233B4
F0 A3 8E B4
4C D8 B4 DF
𣎴
𣎴
𣎴
𣎴
18
لك أن كلا
U+0644 U+0643 U+0020 U+0623 U+0646 U+0020 U+0643 U+0644 U+0627
D9 84 D9 83 20 D8 A3 D9 86 20 D9 83 D9 84 D8 A7
44 06 43 06 20 00 23 06 46 06 20 00 43 06 44 06 27 06
لك أن كلا
لك أن كلا
لك أن كلا
لك أن كلا
Obsolete and historical HtmlEncode methods:
This table is included only for computer-archeological reasons. **It does not apply to .NET Framework 4.8, nor any versions of ASP.NET Core and ASP.NET-for-.NET 5 or later.
#
Input
Code-point(s)
UTF-8 bytes
UTF-16 bytes
System.Web.HttpUtility.HtmlEncode (ASP.NET 1.1 and 2.0)
Microsoft.Security.Application.Encoder.HtmlEncode(false)
Microsoft.Security.Application.Encoder.HtmlEncode(true)
0
abc
U+0061 U+0062 U+0063
61 62 63
61 00 62 00 63 00
abc
abc
abc
1
<
U+003C
3C
3C 00
<
<
<
2
>
U+003E
3E
3E 00
>
>
>
3
&
U+0026
26
26 00
&
&
&
4
"
U+0022
22
22 00
"
"
"
5
'
U+0027
27
27 00
'
'
'
6
Ÿ
U+009F
C2 9F
9F 00
Ÿ
Ÿ
Ÿ
7
U+00A0
C2 A0
A0 00
 
 
8
ÿ
U+00FF
C3 BF
FF 00
ÿ
ÿ
ÿ
9
ā
U+0101
C4 81
01 01
ā
ā
ā
10
~
U+007E
7E
7E 00
~
~
~
11
| `U+007F` | `7F` | `7F 00` |


12
£
U+00A3
C2 A3
A3 00
£
£
£
13
ÿ
U+00FF
C3 BF
FF 00
ÿ
ÿ
ÿ
14
Ḃ
U+1E02
E1 B8 82
02 1E
Ḃ
Ḃ
Ḃ
15
💩
U+1F4A9
F0 9F 92 A9
3D D8 A9 DC
💩
💩
💩
16
𣎴
U+233B4
F0 A3 8E B4
4C D8 B4 DF
𣎴
𣎴
𣎴
17
𣎴
U+233B4
F0 A3 8E B4
4C D8 B4 DF
𣎴
𣎴
𣎴
18
لك أن كلا
U+0644 U+0643 U+0020 U+0623 U+0646 U+0020 U+0643 U+0644 U+0627
D9 84 D9 83 20 D8 A3 D9 86 20 D9 83 D9 84 D8 A7
44 06 43 06 20 00 23 06 46 06 20 00 43 06 44 06 27 06
لك أن كلا
لك أن كلا
لك أن كلا
HtmlEncode methods in .NET 5
#
Input
Code-point / Runes
UTF-8 bytes
UTF-16 bytes
System.Net.WebUtility.HtmlEncode
System.Web.HttpUtility.HtmlEncode (.NET 5)
System.Text.Encodings.Web.HtmlEncoder
0
abc
97 98 99
61 62 63
61 00 62 00 63 00
abc
abc
abc
1
<
60
3C
3C 00
<
<
<
2
>
62
3E
3E 00
>
>
>
3
&
38
26
26 00
&
&
&
4
"
34
22
22 00
"
"
"
5
'
39
27
27 00
'
'
'
6
Ÿ
159
C2 9F
9F 00
Ÿ
Ÿ
Ÿ
7
160
C2 A0
A0 00
 
 
 
8
ÿ
255
C3 BF
FF 00
ÿ
ÿ
ÿ
9
ā
257
C4 81
01 01
ā
ā
ā
10
~
126
7E
7E 00
~
~
~
11
| `127` | `7F` | `7F 00` |
``

12
£
163
C2 A3
A3 00
£
£
£
13
ÿ
255
C3 BF
FF 00
ÿ
ÿ
ÿ
14
Ḃ
7682
E1 B8 82
02 1E
Ḃ
Ḃ
Ḃ
15
💩
128169
F0 9F 92 A9
3D D8 A9 DC
💩
💩
💩
16
𣎴
144308
F0 A3 8E B4
4C D8 B4 DF
𣎴
𣎴
𣎴
17
𣎴
144308
F0 A3 8E B4
4C D8 B4 DF
𣎴
𣎴
𣎴
18
لك أن كلا
1604 1603 32 1571 1606 32 1603 1604 1575
D9 84 D9 83 20 D8 A3 D9 86 20 D9 83 D9 84 D8 A7
44 06 43 06 20 00 23 06 46 06 20 00 43 06 44 06 27 06
لك أن كلا
لك أن كلا
لك أن كلا

How to use a CNG (or AES-NI enabled instruction set) in .NET?

I Currently perform a large amount of encryption/decryption of text in c# using AES.
With a pure software system it can take quite a processor hit for a decent amount of time for the lots of datasets required to be decrypted. I know Intel have came out with their AES-NI instruction set and AMD has come out with similar.
I'm using .NET 4.0, I know that the windows CNG framework makes use of these instruction sets, but it does not appear that AesManaged in the .NET world does the same.
There is a fantastic project "CLR Security" which makes a gateway from .NET 3.5 to the windows CNG, however it hasn't been maintained in a year and I'd rather not (if possible) jump on a dying project.
There is a CNGProvider class in .NET 4 but there doesn't appear to be adequate documentation to cobble together a working decryption from it for AES.
Does anyone have experience with the topic they could point me in the right direction on how to get AES-NI implemented in a pure .NET environment, using pre-made classes, without having to do a p/invoke directly from c#? (It'd be fine if there was a wrapper class doing it, as long as it was maintained).

What about AesCryptoServiceProvider? It says that uses CAPI, and so
hopefully CNG if available. – Rup
This comment has helped tremendously, after doing some digging it looks like AesCryptoServiceProvider will use AES-NI if available. I cannot find any 'official' documentation from Microsoft on this however. When running simple timing benchmarks the difference is ~15x faster so either the API itself is massively optimized (which for a 15x increase is pretty nice optimization) or it uses the AES-NI instruction set.
Unfortunately I don't have a non AES-NI box to test on, but if I ever get one I'll update this thread with results.
So I'm pretty confident this is the API to use for AES-NI but cannot guarantee without further testing.

How to use a CNG (or AES-NI enabled instruction set) in .NET?
I'm going to focus on the AES-NI instruction set question. I found it to be interesting since I wondered it myself (for use in C and C++).
Microsoft added AES-NI support to Visual Studio 2008 SP1 (_MSC_FULL_VER >= 150030729). The earliest you can observe AES-NI in Microsoft products is circa 2008 since earlier compilers did not support it. That means Server 2008 has it, and possibly Windows Vista via a Service Pack, and above.
According to Does MS Crypto API supports AES and AES-NI processor instructions?, both rsaenh.dll and bcryptprimitives.dll have it. The statements made by IvanP tested on Windows 7 and Windows 10.
However, testing on Windows 8.1 reveals...
# Using a Developer Command prompt so dumpbin is on-path:
> dumpbin /disasm c:\Windows\System32\rsaenh.dll > rsaenh.dll.txt
> dumpbin /disasm c:\Windows\System32\bcryptprimitives.dll > bcryptprimitives.dll.txt
Then:
# Using a GitBash terminal for grep
$ grep -i aes rsaenh.dll.txt
$
And:
$ grep -i aes bcryptprimitives.dll.txt
000000018000234A: 66 0F 3A DF C0 00 aeskeygenassist xmm0,xmm0,0
0000000180002363: 66 0F 38 DB C0 aesimc xmm0,xmm0
000000018000237E: 66 0F 38 DC 41 10 aesenc xmm0,xmmword ptr [rcx+10h]
0000000180002384: 66 0F 38 DC 41 20 aesenc xmm0,xmmword ptr [rcx+20h]
000000018000238A: 66 0F 38 DC 41 30 aesenc xmm0,xmmword ptr [rcx+30h]
0000000180002390: 66 0F 38 DC 41 40 aesenc xmm0,xmmword ptr [rcx+40h]
0000000180002396: 66 0F 38 DC 41 50 aesenc xmm0,xmmword ptr [rcx+50h]
000000018000239C: 66 0F 38 DC 41 60 aesenc xmm0,xmmword ptr [rcx+60h]
00000001800023A2: 66 0F 38 DC 41 70 aesenc xmm0,xmmword ptr [rcx+70h]
00000001800023AF: 66 0F 38 DC 01 aesenc xmm0,xmmword ptr [rcx]
00000001800023B4: 66 0F 38 DC 41 10 aesenc xmm0,xmmword ptr [rcx+10h]
00000001800023C3: 66 41 0F 38 DD 02 aesenclast xmm0,xmmword ptr [r10]
000000018001936E: 66 0F 38 DC 41 10 aesenc xmm0,xmmword ptr [rcx+10h]
0000000180019374: 66 0F 38 DC 41 20 aesenc xmm0,xmmword ptr [rcx+20h]
000000018001937A: 66 0F 38 DC 41 30 aesenc xmm0,xmmword ptr [rcx+30h]
0000000180019380: 66 0F 38 DC 41 40 aesenc xmm0,xmmword ptr [rcx+40h]
0000000180019386: 66 0F 38 DC 41 50 aesenc xmm0,xmmword ptr [rcx+50h]
000000018001938C: 66 0F 38 DC 41 60 aesenc xmm0,xmmword ptr [rcx+60h]
0000000180019392: 66 0F 38 DC 41 70 aesenc xmm0,xmmword ptr [rcx+70h]
000000018001939F: 66 0F 38 DC 01 aesenc xmm0,xmmword ptr [rcx]
00000001800193A4: 66 0F 38 DC 41 10 aesenc xmm0,xmmword ptr [rcx+10h]
00000001800193B3: 66 41 0F 38 DD 02 aesenclast xmm0,xmmword ptr [r10]
000000018001952E: 66 0F 38 DE C4 aesdec xmm0,xmm4
0000000180019533: 66 0F 38 DE CC aesdec xmm1,xmm4
0000000180019538: 66 0F 38 DE D4 aesdec xmm2,xmm4
000000018001953D: 66 0F 38 DE DC aesdec xmm3,xmm4
000000018001954B: 66 0F 38 DF C4 aesdeclast xmm0,xmm4
0000000180019550: 66 0F 38 DF CC aesdeclast xmm1,xmm4
0000000180019555: 66 0F 38 DF D4 aesdeclast xmm2,xmm4
000000018001955A: 66 0F 38 DF DC aesdeclast xmm3,xmm4
000000018002E8B5: 66 0F 38 DE 41 10 aesdec xmm0,xmmword ptr [rcx+10h]
000000018002E8BB: 66 0F 38 DE 41 20 aesdec xmm0,xmmword ptr [rcx+20h]
000000018002E8C1: 66 0F 38 DE 41 30 aesdec xmm0,xmmword ptr [rcx+30h]
000000018002E8C7: 66 0F 38 DE 41 40 aesdec xmm0,xmmword ptr [rcx+40h]
000000018002E8CD: 66 0F 38 DE 41 50 aesdec xmm0,xmmword ptr [rcx+50h]
000000018002E8D3: 66 0F 38 DE 41 60 aesdec xmm0,xmmword ptr [rcx+60h]
000000018002E8D9: 66 0F 38 DE 41 70 aesdec xmm0,xmmword ptr [rcx+70h]
000000018002E8E6: 66 0F 38 DE 01 aesdec xmm0,xmmword ptr [rcx]
000000018002E8EB: 66 0F 38 DE 41 10 aesdec xmm0,xmmword ptr [rcx+10h]
000000018002E8FA: 66 41 0F 38 DF 02 aesdeclast xmm0,xmmword ptr [r10]
000000018003F458: 66 0F 38 DC E8 aesenc xmm5,xmm0
000000018003F45D: 66 0F 38 DC D8 aesenc xmm3,xmm0
000000018003F462: 66 0F 38 DC E0 aesenc xmm4,xmm0
000000018003F467: 66 0F 38 DC F0 aesenc xmm6,xmm0
000000018003F475: 66 0F 38 DD EF aesenclast xmm5,xmm7
000000018003F47A: 66 0F 38 DD DF aesenclast xmm3,xmm7
000000018003F47F: 66 0F 38 DD E7 aesenclast xmm4,xmm7
000000018003F492: 66 0F 38 DD F7 aesenclast xmm6,xmm7
So, on modern Windows, you need to use something that depends on bcryptprimitives.dll. I don't know what .Net primitives enlist bcryptprimitives.dll.
I also checked the following DLLs on Windows 8.1, and there were no AES-NI instructions present:
advapi32.dll
bcrypt.dll
crypt32.dll
cryptbase.dll
cryptcatsvc.dll
cryptdlg.dll
cryptdll.dll
cryptext.dll
cryptnet.dll
cryptowinrt.dll
cryptsp.dll
cryptsvc.dll
There's not much information about the subject on Microsoft's site. I got two hits from csp "aes-ni" site:microsoft.com, and 0 hits for csp "aesni" site:microsoft.com. Whatever is going on, Microsoft is keeping it secret.

I had worked in the earliest of chipsets that had these features. At that time Windows 7 didn't have the ability to work with AES. I resorted to the then available Ubuntu and used the Intel doc and with some inline assembly did a cpuid. That served my purpose of a training. Nevertheless one thing I learned is "Intel secure key" was made available almost at the same time as "AES-NI". So if I found RDRAND instruction in the chipset that means I "probably" had AES-NI. So this way the simplest I can do (but not quite documented) is
//PF_RDRAND_INSTRUCTION_AVAILABLE is not documented yet as part of MSDN API as of //this writing
IsProcessorFeaturePresent(PF_RDRAND_INSTRUCTION_AVAILABLE);
We can also use the CPU intrinsics this way
https://learn.microsoft.com/en-us/cpp/intrinsics/cpuid-cpuidex?view=vs-2019
Also see below document for more "proof".
https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1894.pdf

mono, xsp2, npgsql Could not load assembly

I am writing web service and I have two classes:
<%# WebService Language="C#" Class="CairoParts.ProductsInfoWS.ProductsInfoWS.cs" %>
using System;
using System.IO;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
namespace CairoParts.ProductsInfoWS
{
[WebService(Namespace = "http://localhost:8081/ProductsInfoWS")]
public class ProductsInfoWS : System.Web.Services.WebService
{
[WebMethod]
public List<string> ReceiveFile(byte[] bytes, string fileName, string supplier)
{
}
{
}
and Database.cs:
using System;
using System.Data;
using System.Configuration;
using Npgsql;
namespace CairoParts.ProductsInfoWS
{
public class Database
{
}
}
When i fire xsp2 and type in browser http://localhost:8081/ProductsInfoWS.asmx i get this error:
/usr/lib/mono/2.0/gmcs.exe:22858): WARNING **: The following assembly referenced from /tmp/vadmin-temp-aspnet-0/b8083b1b/assembly/shadow/94001eba/43c949ff_d7c95745_00000001/CairoParts.ProductsInfoWS.dll could not be loaded:
Assembly: Npgsql (assemblyref_index=2)
Version: 2.0.6.0
Public Key: 5d8b90d52f46fda7
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/tmp/vadmin-temp-aspnet-0/b8083b1b/assembly/shadow/94001eba/43c949ff_d7c95745_00000001).
My Npgsql.dll file is in 'bin' directory. Whats wrong...

It could be that the dll Npgsql.dll is strong-name signed and therefore needs to be placed in the global assembly cache (GAC), have you tried copying the dll into the location where the GAC is?
Hope this helps,
Best regards,
Tom.

Run:
monodis --assembly bin/Npgsql.dll
to verify that your assembly has the same version and public key that is referenced from CairoParts.ProductsInfoWS.dll.
In my local Mono installation compiled from sources, I have 3 directories in the gac for Npgsql:
1.0.5000.0__5d8b90d52f46fda7
2.0.0.0__5d8b90d52f46fda7
4.0.0.0__5d8b90d52f46fda7
and none of them has version 2.0.6.0.
Perhaps you need to recompile CairoParts.ProductsInfoWS.dll so that it references the assemblies present in your system.

I recompiled my project and run command that you have suggested, here's the output:
Assembly Table
Name: Npgsql
Hash Algoritm: 0x00008004
Version: 2.0.6.0
Flags: 0x00000001
PublicKey: BlobPtr (0x000020b1)
Dump:
0x00000000: 00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00
0x00000010: 00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00
0x00000020: 2B 3C 59 0B 2A 4E 3D 34 7E 68 78 DC 0F F4 D2 1E
0x00000030: B0 56 A5 04 20 25 0C 66 17 04 43 30 70 1D 35 C9
0x00000040: 80 78 A5 DF 97 A6 2D 83 C9 A2 DB 2D 07 25 23 A8
0x00000050: FC 49 13 98 25 4C 6B 89 32 9B 8C 1D CE F4 3A 1E
0x00000060: 7A A1 61 53 BC EA 2A E9 A4 71 14 56 24 82 6F 60
0x00000070: D7 C8 E7 1C D0 25 B5 54 A0 17 7B D9 35 A7 80 96
0x00000080: 29 F0 A7 AF C7 78 EB B4 AD 03 3E 1B F5 12 C1 A9
0x00000090: C6 CE EA 26 B0 77 BC 46 CA C9 38 00 43 5E 77 EE
Culture:
It's look like npgsql versions are ok, but webservice still yields the same error.
I kinda solve this issue by putting Database class in webservice asmx file, but it's more like workaround then a real solution...