Hi
Before i try to remove exifInfo with jpg image, i want to get JpegFormat.ExifValues,but it will crash in the environment where application verifier is turned on.
Step:
1.Build AppVerifier Environment with winsdk.
2.Add my application to Application Verifier and save.
3.when i try to get JpegFormat.ExifValues, it crashes.and i can’t catch this exception,maybe the callStack picture Can help solve this problem.
thanks！
callStack.png (32.0 KB)
1 Like
Please share following details and we’ll look into this issue:
- API version (e.g. 20.5, 20.7)
- Are you using any other GroupDocs or Aspose API with Metadata?
- Sample image file
- Sample code that you are using
Can you please share a screencast showing the crash/issue?
I apologize for the late reply. I recently wanted to write a simple example and it took some time to reproduce this problem, so sorry.
Here is the sample code:sample code
maybe you should attach with native, otherwise you may can not see this exception.
and the api version is 19.5, the sample picture is also in this compressed package, the path is \bin\debug\netcoreapp3.1\test.jpg,
Today I tried to reproduce this problem with this sample code and it succeeded. I hope you can help me solve this problem. Thank you very much.
We tried to reproduce this issue but application/code was executed without any issue.
Please share following details:
- Which version of Application Verifier is connected to the test app during its execution? Is the Application Verifier built for x86 or x64 platform?
- Please also share the full App Verifier configuration (including properties)
- Try to get a full stack of the exception including unmanaged code. To do this you may need to download appropriate debug symbols for native Windows DLLs. Here you can find some brief instructions on how to download the symbols from MS servers
- Is the issue reproduced with later versions of GroupDocs.Metadata?
- Is the exception thrown when the code is running in the main thread?
Another thing we noticed about the code is that the JpegFormat instance is not disposed if the execution doesn’t hit the last catch block. It can lead to a variety of unexpected results, so we would recommend you to fix it. We modified DoTransform method:
public static void DoTransform(object param)
{
string[] commandlineArgs = Environment.GetCommandLineArgs();
string filePath = commandlineArgs[1];
using (var format = new JpegFormat(filePath))
{
string copyRight = null;
LangAlt rights = null;
if (format.ExifValues != null)
{
copyRight = format.ExifValues.Copyright;
}
if (format.XmpValues != null)
{
rights = format.XmpValues.Schemes.DublinCore.Rights;
}
format.RemoveExifInfo();
format.RemoveXmpData();
if (copyRight != null)
{
format.ExifValues.Copyright = copyRight;
}
if (rights != null)
{
format.XmpValues.Schemes.DublinCore.Rights = rights;
}
// A Save method call is missing here. All changes remain unsaved.
}
}
We executed DoTransform method in only one thread in a single application instance. So, we didn’t require Mutex at all. But If you are using it, please note that the Mutex class implements the IDisposable interface. So you should call the Dispose method for any Mutex instance that is not needed anymore. A ReleaseMutex call is not enough to release all acquired resources.
Thanks！
I modified the code according to your suggestion, but it doesn’t seem to work, I’m sorry for that.I can still reproduce this problem very stably.
Details:
1.The Application Verifier specific version is 10.0.18362.and it’s built for x64 platform
2.this issue also can reprodeced when i use 20.9.0.0 GroupDocs.Metadata
3.the exception thrown not in main thread,but in a thread start in application verifier, more info can see in zip.Groupdocs.zip (310.6 KB)
Hope my information is helpful to you
Thank you for the details. We’ll further investigate this issue and notify you about the outcomes. In case of any further information, we’ll let you know.
Thank you and look forward to your reply！
Unfortunately, the provided information didn’t help to reproduce the issue at our end. We’re still unable to get the exception described in the screenshots. So, let’s try to investigate this scenario in a different way. We’ve tried to boil the issue down to a minimum amount of code required to nail the exception. As a result, we created three sample projects with a slightly different implementation of the Program class:
Please go through the following steps using each of the test projects:
- Open the project in Visual Studio and replace the “/path/to/your/license” string with a path to your valid license
- Select the “Debug”->“Windows”->“Exception Settings” menu item. Right-click inside the opened “Exception Settings” window and choose “Restore Defaults”
- Run the project in debug mode with connected Application Verifier
- Please share the results. Did you get any exceptions? Is the output file created? (It can be found in the “RemoveMetaDataTest\bin\Debug\netcoreapp3.1” directory if the program executed successfully)
I also can reproduce this issue with Project 1(i just try this project) .I can’t wait to tell you some important information, so I didn’t continue to try other projects
callstack_new.png (152.6 KB)
It suddenly occurred to me that I seem to have a very important message that I forgot to tell you！
I’m not run the project in debug mode directly （i also can’t reproduce with this situation）
my step:
1. ready to connect application verifier.
2.open cmd,and run RemoveMetaDataTest.exe (such as:
C:\Users\User>C:\Users\User\Desktop\FromGroupDocs\RemoveMetaDataTest1\RemoveMetaDataTest\RemoveMetaDataTest\bin\Debug\netcoreapp3.1\RemoveMetaDataTest.exe)
3.and then, In VS2019 ->Debug -> Attach to process -> Find RemoveMetaDataTest.exe -> Attach
to: Native code(Most important，can not use auto, will set to managed)
4.then throw exception.
I am deeply discarded for not expressing this important information clearly, it may have wasted a lot of your time. so sorry,you can try it,thanks.
Your feedback was helpful. Please now answer the following:
-
We believe that the reason why you keep getting the exception is that you are trying to connect the native debugger to an application written in managed code. Please disable Application Verifier and try to attach the debugger to the process in native mode. It just throws exactly the same exception at our end. This means Application Verifier has nothing to do with the exception you can see in Visual Studio. The way to debug the application, we suggested in the previous answer seems to be more natural. When you start debugging in Visual Studio, you let it decide which debugger to use in which situation. Please also check the “launchSettings.json” config in the provided sample projects (shared earlier). All of them contain the “nativeDebugging” setting set to “true”. Setting this parameter, we tell Visual Studio to debug native code as well as managed code. When debugging the code sample according to the suggested scenario it produces no errors. Application Verifier also generates a clean log containing no errors or warnings. Moreover, the output file is created when running any of the provided sample projects. This means that no exceptions are thrown during code execution. We can’t find any reasons not to trust the results yielded by this test scenario. Could you please explain why you prefer to attach a specific debugger rather than start the debugging process in Visual Studio? Hope it will help us to find the issue if it’s caused by GroupDocs.Metadata.
-
We have some concerns regarding utilizing Application Verifier with software written in C#. According to the official documentation here, this tool is intended to test applications written in unmanaged (native) code. It’s not directly stated that it doesn’t work with managed applications, but we believe there may be undocumented issues related to the interaction of Application Verifier with the CLR debugger.
We can also refer to some articles written by Microsoft representatives that say Application Verifier is not the right tool for testing managed code.
Could you please list the code issues you would like to detect and eliminate with Application Verifier? Which tests under the Basics category are important for you? It would help us to adjust our code accordingly.
I am very thankful that my feedback is helpful to you. i read the article you sent me, it is very helpful to me, thank you.
I observed the same phenomenon as you which can see the same exception when disable application.
But when i comment the code related to ExifValues,
//if (format.ExifValues != null) {
//copyRight = format.ExifValues.Copyright;
//}
// format.RemoveExifInfo();
it won’t throw this exception. isn’t it the important message? On this problem, I am not prefer to attach a specific debugger rather than start the debugging process in visual studio. In the fact, my application(not the sample code) contains native code and managed code, and when I connect Application Verifier with my application, when run the code to here, will result to crash without any error message. (in sample code you also can watch this phenomenon: when you connected the RemoveMetaDataTest.exe to Application Verifier, and run this exe in cmd, it will crash and won’t get the output.jpg, although i have not attach with this process.)
This exception cannot be caught, this is the most troublesome place for me. i am afraid that my application will crash. i may not give you more helpful info,but the only thing i know is the problem is in ExifValues .i also don’t know why when i start the debugging process in visual studio can’t work for this exception. but i think it is certain that there is a problem in GroupDocs.Meta JpegFormat.ExifValues.get() and RemoveExifInfo(),Please help me to find this issue and improve this.(maybe buffer overrun error)
And in Application Verifier Basics category, i want to detect exceptions, handles and heaps.Thanks.
That’s true, so let’s dive into this issue and try to sort it out. If we run the test application with connected Application Verifier it definitely crashes, since, we don’t get the output file. The exception is not thrown because we don’t attach a native debugger which is required to see errors produced by Application Verifier. But let’s try to disable the “Basics->Exceptions” subcategory in the Application Verifier settings and run the test app again. It is successfully executed this time, so now we know the exact test that leads to application crash. The tooltip for the “Exceptions” category in the Application Verifier UI says the following: “Detects first chance access violation exceptions”. What is the first chance exception? Basically, all exceptions start as first chance exceptions. But not all first chance exceptions lead to application termination because some of them can be handled in the code. When a first chance exception is thrown the debugger (or Application Verifier in our case) doesn’t know if the exception will be caught and handled. So, Application Verifier just exposes all thrown exceptions without even knowing if they will lead to an actual application crash. And it does this by throwing its own exception that actually terminates the application with an error. Please refer to this article to learn more about first chance exceptions. Please also check this discussion of the mentioned behavior here.
We believe, If the exception wasn’t handled by the code at some point, the application would eventually crash in the scenario when Application Verifier is not connected. So, it can’t indicate any particular issues related to the library. Please also note that the exception in managed code is not equal to the exception in native code. Application Verifier detects only native exceptions, and the one we observe could take place at the border of the managed and unmanaged code outside the library.
But why the exception is not thrown when we debug the application inside Visual Studio with Application Verifier connected? We think, this is simply because the debugger intercepts some first chance exceptions but doesn’t pass them to Application Verifier. That’s why we would suggest this approach for testing your code with Application Verifier.
Please let us know if this explanation helps.
Yes, this is very helpful for me! It’s you who gave me a deeper understanding of first chance exception.
Thank you very much! I know how to deal with this issue, thanks.
1 Like