C# File.Create terminating WimForm app wiith no error thrown ?
-
Is it possible that you're getting a "process corrupted state" exception? Those won't be caught by a
try..catchblock unless the method has theHandleProcessCorruptedStateattribute applied. HandleProcessCorruptedStateExceptionsAttribute Class (System.Runtime.ExceptionServices) | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks, Richard, "process corrupted state" reminds me of what I see in the mirror these days :omg: I'm retesting today in a new solution with PostSharp and ReSharper not in use.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Update: revised code to use full Type names, not var; used hard-coded filepath. Now, in VS 2019 using FW 4.8, File.Create terminates the app with no error message. I tried wrapping the call in a Try/Catch: terminates the app without ever reaching the Catch clause. Note: i can't find any error reports on the behavior of File,Create described here. A few years ago, the code shown here was a standard part of the serialization library i wrote, and worked fine. The other part of the library, which uses XML serialization, works without errors. Note: the code shown compiles, but, fails in the first 'using block. File,Create moved outside the using statement also fails the same way. So, there's nothing specifically GZippy where the code fails. // reqiured usings using System.IO; using System.IO.Compression; using System.Runtime.Serialization;
public static void GZSerialize(T instance, string baseFolderPath, string filename1)
{
dcs = new DataContractSerializer(typeof(T));string fullfilename = baseFolderPath + "/" + filename1 + (usegzip + @".gz"; //if (File.Exists(fullfilename )) //{ //File.Delete(fullfilename ); //} string fullfilename = @"C:\\Users\\Win-Ten\\Desktop\\fordata\\test4.gz"; **// fails here** using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write)) { using (GZipStream compressionStream = new GZipStream(compressedFileStream, CompressionLevel.Optimal, true)) { dcs.WriteObject(compressionStream, instance); compressionStream.Close(); } }}
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Bill, Check to see if Controlled Folder Access[^] is causing the issue. I think you had a similar error a few years ago[^]. :) Best Wishes, -David Delaune
-
Bill, Check to see if Controlled Folder Access[^] is causing the issue. I think you had a similar error a few years ago[^]. :) Best Wishes, -David Delaune
Thanks, David, I think I can exclude that hypothesis based on the fact that using standard DataContract/DataMember serialization to XML to the same folder is reliable. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, David, I think I can exclude that hypothesis based on the fact that using standard DataContract/DataMember serialization to XML to the same folder is reliable. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Ok, Just keep in mind that Windows Defender now performs behavioral analysis so it might allow certain actions while blocking others. Good Luck. :)
Thanks, David, I have checked both Win-Def and EmsiSoft (my active malware filter/firewall), no evidence for this rather improbable scenario. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, David, I have checked both Win-Def and EmsiSoft (my active malware filter/firewall), no evidence for this rather improbable scenario. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Alright, Then you should have no problems determining why your process is exiting. Did you try to attach a debugger? Did you check the event log and get the exit code[^]? Have you tried using Gflags[^]? The path you gave in your top level post:
string fullfilename = @"C:\Users\Win-Ten\Desktop\fordata\test4.gz";
would be protected by controlled folder access (if enabled). Best Wishes, -David Delaune
-
Alright, Then you should have no problems determining why your process is exiting. Did you try to attach a debugger? Did you check the event log and get the exit code[^]? Have you tried using Gflags[^]? The path you gave in your top level post:
string fullfilename = @"C:\Users\Win-Ten\Desktop\fordata\test4.gz";
would be protected by controlled folder access (if enabled). Best Wishes, -David Delaune
Thanks, David, but, the convers you are raising have alrady been addressed, and should be obvious if you read the previous messages.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Update: revised code to use full Type names, not var; used hard-coded filepath. Now, in VS 2019 using FW 4.8, File.Create terminates the app with no error message. I tried wrapping the call in a Try/Catch: terminates the app without ever reaching the Catch clause. Note: i can't find any error reports on the behavior of File,Create described here. A few years ago, the code shown here was a standard part of the serialization library i wrote, and worked fine. The other part of the library, which uses XML serialization, works without errors. Note: the code shown compiles, but, fails in the first 'using block. File,Create moved outside the using statement also fails the same way. So, there's nothing specifically GZippy where the code fails. // reqiured usings using System.IO; using System.IO.Compression; using System.Runtime.Serialization;
public static void GZSerialize(T instance, string baseFolderPath, string filename1)
{
dcs = new DataContractSerializer(typeof(T));string fullfilename = baseFolderPath + "/" + filename1 + (usegzip + @".gz"; //if (File.Exists(fullfilename )) //{ //File.Delete(fullfilename ); //} string fullfilename = @"C:\\Users\\Win-Ten\\Desktop\\fordata\\test4.gz"; **// fails here** using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write)) { using (GZipStream compressionStream = new GZipStream(compressedFileStream, CompressionLevel.Optimal, true)) { dcs.WriteObject(compressionStream, instance); compressionStream.Close(); } }}
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
@Randor Thanks to David (aka Randor) ! Well, turns out I did not look deeply enough into the EmsiSoft AV/Firewall records, as David suggested. Note: size of test file saved as .xml 1017; size saved as .gz 369. EmsiSoft was quarantining the WinForm app .exe. I set permission for the entire folder containing my C# work in progress ...code works ... ... setting permission for VS 2019 and 2022 had no effect. Why the whole folder ? I was too lazy to set it for one specific project. Here's what the kinks were: 1. no run-time notification pop-up from EmsiSoft which is normally ... a frequent popper-upper. And, once quarantined, why should the app run partially at all ? I will write about this to them, and, aaso ask them what could happen if I were using GitHub storage. 2. why should standard XML writing:
using (var writer = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write
//FileIOPermissionAccess.AllAccess
))
{
dcs.WriteObject(writer, instance);
}work, but, why does this:
using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write))
{
using (GZipStream compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, false))
{
dcs.WriteObject(compressionStream, instance);
compressionStream.Close();
}
}trigger AV interception ? Is there an MS bug here ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
@Randor Thanks to David (aka Randor) ! Well, turns out I did not look deeply enough into the EmsiSoft AV/Firewall records, as David suggested. Note: size of test file saved as .xml 1017; size saved as .gz 369. EmsiSoft was quarantining the WinForm app .exe. I set permission for the entire folder containing my C# work in progress ...code works ... ... setting permission for VS 2019 and 2022 had no effect. Why the whole folder ? I was too lazy to set it for one specific project. Here's what the kinks were: 1. no run-time notification pop-up from EmsiSoft which is normally ... a frequent popper-upper. And, once quarantined, why should the app run partially at all ? I will write about this to them, and, aaso ask them what could happen if I were using GitHub storage. 2. why should standard XML writing:
using (var writer = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write
//FileIOPermissionAccess.AllAccess
))
{
dcs.WriteObject(writer, instance);
}work, but, why does this:
using (FileStream compressedFileStream = new FileStream(fullfilename, FileMode.OpenOrCreate, FileAccess.Write))
{
using (GZipStream compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, false))
{
dcs.WriteObject(compressionStream, instance);
compressionStream.Close();
}
}trigger AV interception ? Is there an MS bug here ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
@Randor Well, Sir, i think it is ... You ... who solved it ! :) But, please indulge my OCD re language: i do consider understanding the source of an anomaly as not equatable with "solved." Yet, it was moi who used thr word "solved: :omg: End of rant. What a wonderful education code that worked for years ... and then, breaks ... can offer :) Please come to Chiang Mai asap so i can take you for a scrumptious Thai dinner. cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
