[SOLVED] Crash .net runtime

Problem has been resolved :dance:
Thanks a lot writhziden for taking a look at it :thumbsup2:
 

Attachments

  • cdb25d1379.png
    cdb25d1379.png
    39.6 KB · Views: 7
That I have the Dutch language installed would be an odd cause, half of the crash dumps are from when I only had the english language installed.

I have attached a new zip file from a user on EF where I experience this problem.

Ah, it's not crashing due to the .dmps; it is crashing due to ProcessList.txt, a seemingly empty file that is mysteriously 1KB in size. If I open it in any text editor, the file is empty, so why is it taking up 1 KB?

At any rate, I'll look into why the apps crash when opening that file. I will try to roll out an update in the next couple weeks. I am still in the process of getting the apps compatible with Windows 8.1 and Windows 10 for old driver list functionality on those OSes. That is quite an endeavor since that information is deeply embedded in so much of how the apps analyze .dmps

That's because a text editor is inherently a text editor. They do not show every piece of data a file holds. You need to use a hex editor or raw read for that.

Read up about Byte Order Marks (BOM): https://en.wikipedia.org/wiki/Byte_order_mark

This file contains just two bytes 0xFF 0xFE. They signify that this is a UTF-16 LE file, and that text editors should read the rest of the file in this format (BOMs alleviate ambiguity between all of the various Unicodes).

In essence this is a perfectly normal, perfectly healthy empty file. But it's UTF-16 LE rather than ASCII/"ANSI" encoded. It's a good idea to use some form of Unicode anyway though since they support lots of different character sets much better [Windows natively used UTF16-LE most of the time, although arguably UTF8 is a much better format, and is also what *nix systems tend to use].

Overall though they're a bit of a pain to code with in C/C++ languages and I've run into every problem under the sun over the years with development versions of SFCFix & trying to make it support lots of languages. But it's worth it in the end :)
 
Read More:

That's because a text editor is inherently a text editor. They do not show every piece of data a file holds. You need to use a hex editor or raw read for that.

Read up about Byte Order Marks (BOM): https://en.wikipedia.org/wiki/Byte_order_mark

This file contains just two bytes 0xFF 0xFE. They signify that this is a UTF-16 LE file, and that text editors should read the rest of the file in this format (BOMs alleviate ambiguity between all of the various Unicodes).

In essence this is a perfectly normal, perfectly healthy empty file. But it's UTF-16 LE rather than ASCII/"ANSI" encoded. It's a good idea to use some form of Unicode anyway though since they support lots of different character sets much better [Windows natively used UTF16-LE most of the time, although arguably UTF8 is a much better format, and is also what *nix systems tend to use].

Overall though they're a bit of a pain to code with in C/C++ languages and I've run into every problem under the sun over the years with development versions of SFCFix & trying to make it support lots of languages. But it's worth it in the end :)

Yeah, I figured there might be some other language formatting in that file. A purely empty .txt file has always shown up at 0 KB on my systems. It makes sense that it would be Hex format, but I've never been very comfortable working in Hex and tend to avoid it. Maybe someday when I can find time, I will try to learn how it works.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top