Read JObject Property: System.Security.VerificationException: Operation could destabilize the runtime

[kelilive]

Description

JObject access seems to be prone to instability in windows service, causing runtime errors, at least when accessing its attributes. This problem is fatal. At present, if your team cannot give an effective solution in time, I may have to consider how to bypass this problem, but NewtonSoft.Json serialization is no problem.

Reproduction Steps

Example code:

var client = new RestClient(new RestClientOptions(WeatherResources.BaseUrl) { MaxTimeout = -1 });
var request = new RestRequest(WeatherResources.WeatherApi);
request.AddQueryParameter(WeatherResources.CityParameter, cityCode);
request.AddQueryParameter(WeatherResources.AppKeyParameter, WeatherResources.WeatherAppKey);
var response = client.Execute(request);
if (response.StatusCode != HttpStatusCode.OK)
    return null;
var data = JObject.Parse(response.Content);
var log = new StringBuilder();
try
{
    log.AppendLine(nameof(data));
    log.AppendLine(JsonConvert.SerializeObject(data));
    log.AppendLine();
    log.AppendLine(WeatherResources.LivesField);
    log.AppendLine(JsonConvert.SerializeObject(data[WeatherResources.LivesField]));
    log.AppendLine();
}
catch (Exception e)
{
    log.AppendLine(e.ToString());
}
File.WriteAllText(DateTime.Now.ToString("D:\\Error.log"), log.ToString());

Log:

data
{"status":"1","count":"1","info":"OK","infocode":"10000","lives":[{"province":"ZheJiang","city":"HangZhou","adcode":"330100","weather":"Cloudy","temperature":"9","winddirection":"北","windpower":"≤3","humidity":"49","reporttime":"2023-11-30 16:06:45","temperature_float":"9.0","humidity_float":"49.0"}]}

lives
System.Security.VerificationException: Operation could destabilize the runtime.
   at (Object , String )
   at SeaBuilding.Persistent.Tools.WeatherTool.GetWeatherReport(String cityCode)

Expected behavior

No response

Actual behavior

No response

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[kelilive]

If it is not run through the windows service, I control the processing through conditional compilation in Debug mode, which is equivalent to a normal console program.

public static void Main()
{
    #if DEBUG
        Collect(false);

    #elif RELEASE
        ServiceBase.Run(new CollectorService());

    #endif
}

[huoyaoyuan]

Which version of runtime are you using? Is it .NET Framework or .NET Core/5+? I remember that .NET Core has disabled IL verification.

[kelilive]

.NET Framework 4.7.2

[kelilive]

Repeated reading and writing will cause unpredictability in file name changes?

[huoyaoyuan]

.NET Framework specific problem should be reported to Developer Community.

Sounds like a runtime issue since it differs for Release configuration, but I'd suggest you to send compiled binaries there.

Repeated reading and writing will cause unpredictability in file name changes?

DateTime.Now.ToString("D:\\Error.log") causes g to be parsed as a datetime format specifier. Consider using $"D:\\Error{DateTime.Now}.log".

[kelilive]

.NET Framework specific problem should be reported to Developer Community.

Sounds like a runtime issue since it differs for Release configuration, but I'd suggest you to send compiled binaries there.

Repeated reading and writing will cause unpredictability in file name changes?

DateTime.Now.ToString("D:\\Error.log") causes g to be parsed as a datetime format specifier. Consider using $"D:\\Error{DateTime.Now}.log".

Sorry, I didn't get a good look

[kelilive]

I remember that this warehouse should be able to handle .net framework issues last year. Do I need to move it there? I will mark it now and resubmit it later. Of course, I will submit it to newtonsoft.json by the way.

My current plan is to use the system's native Json class to handle the Json string parsing problem. This is a data parsing problem caused by RestReponse.Conten(RestSharp).

[kelilive]

Even trying to use the Json class that comes with the system is still futile and has not improved. But then again, the NewtonSoft.Json deserialization reponse.Content(json string) will not report an error, and the Json deserialization that comes with the object system will always fail to throw an exception. When reading attributes, neither method can handle them.
The way I think of now is to try to parse the data in the most primitive way. The task is urgent. I need to find a way to patch and skip this problem.

[kelilive]

It is correct to implement this direction based on regular expression, which has been verified and can avoid the problem based on reading json attributes.

There is also a idea is the algorithm to implement, the core algorithm is the bracket matching algorithm, defining the Node entity class storage data structure, this idea is feasible, the intermediate algorithm can use regular to lazy (XD).

    public static Dictionary<string, string> Match(string json)
    {
        var matches = Regex.Matches(json, Resources.JsonPattern);
        var results = new Dictionary<string, string>();

        foreach (Match match in matches)
        {
            var key = match.Groups[1].Value;
            var value = match.Groups[2].Value;

            results.Add(key, value);
        }

        return results;
    }

[kelilive]

Clarification: It turns out I made a stupid mistake, but this kind of mistake happens very easily and can lead to huge misunderstandings.

// correct type
JsonSerializer.Deserialize(response.Content);

// error type
JsonSerializer.Deserialize(response.Content);

But when it allows me to get the returned results, the text content displayed is unicode encoding. I originally read that the Chinese in repoense.Content is normally visible. So the system serializer doesn't seem to be very friendly. Maybe it's my problem, but it's really not easy to use.

[kelilive]

Clarification: It turns out I made a stupid mistake, but this kind of mistake happens very easily and can lead to huge misunderstandings.

After all, the Json class that comes with the system basically runs well (the previous error was caused by me using the wrong type, and it was easy for me to confuse the types), but Newtonsoft made an error (it will only be exposed when running in a windows service).

// correct type
JsonSerializer.Deserialize(response.Content);

// error type
JsonSerializer.Deserialize(response.Content);

But when it allows me to get the returned results, the text content displayed is unicode encoding. I originally read that the Chinese in repoense.Content is normally visible. So the system serializer doesn't seem to be very friendly. Maybe it's my problem, but it's really not easy to use.

[kelilive]

Therefore, the final problem is most likely to be Newtonsoft.Json's own factors, although it is also possible that the underlying layer is not robust enough.

In addition, I encountered many prompts when reading properties in Newtonsoft.Json. Previously, there was a warning about unstable JToken parsing. Now, more problems with JObject reading properties are exposed. So, I hope Newtonsoft.Json can handle it smoothly.

[kelilive]

I am very sorry, this is my problem, I did not fully realize that a change factor is the obfuscation code. There is no problem after testing simple demo confusion and cannot prove anything. When the modification of the slightly more complicated obfuscator causes hidden dangers to the code, involving problems such as IL code, it causes the program to run malfunctions. I have now basically concluded through the control group experiment that it has something to do with the obfuscator, and this problem need not be paid too much attention.

Regarding json deserialization to obtain Chinese characters, if no one answers, I will initiate an issue separately.

This issue can be closed, of course, there is no good way to decode the problem now.

ChineseDecode.zip