In C++, why does checking if a variable is nullptr may result in Access violation error?

I am primarily a C# programer with often expedtions to C++ land and some stuff I just don't comprehend.

I have a class that has some FFmpeg object as member variable in .h file initialized like this:

AVFormatContext* formatContext = nullptr;

In the destructor of the class at one point I am checking if this object is nullptr like this:

    if(formatContext != nullptr)
        avformat_close_input(&formatContext);

Sadly, the if line causes the following exception:

Invalid argumentException thrown at 0x00007FFEA696920A (avformat-60.dll) in Blabla.exe: 0xC0000005: Access violation reading location 0x0000000

Why is it possible in C++ that a mere check for nullptr causes such an exception ?

I mean I am not trying to use the object, I am just checking is the addresss a nullptr.
I am not even checking for "validity" for the lack of a better word (so is this the "same" object that I think it is or has the address been messed up).

When I see access violation exception it seems to me like someone kidnapped this object and in its place is now potatos, but surely this is not possible ?

Edit

Let me ask you this, we are talking about modern (C++ 17) C++ and note that av_stuff is mostly FFmpeg related library calls.
Is my logic and perception of the problem in the comments below correct ?

AVFormatContext* formatContext = nullptr; // formatContext is ok and initialized as nullptr
...
avformat_fill_the_context_(&formatContext) //formatcontex has been "filled", so its not nullptr anymore but points to a valid object
...
av_do_somestuff(formatContext) //Some call that MESSES UP THE POINTER
...
if(formatContext != nullptr)  //here I get the exception, but my object was messed up earlier 

Is my thought train correct, does stuff happen like this ?

> Why is it possible in C++ that a mere check for nullptr causes such an exception ?

It isn't. The check is not the problem here.

> I mean I am not trying to use the object, I am just checking is the addresss a nullptr.

The pointer is a member of another object, which you haven't shown. Most likely this (and literally this) is where the problem lies.

When you say

> I have a class that has some FFmpeg object as member variable

it tells us that the expression

(formatContext != nullptr)

is really

(this->formatContext != nullptr)

and the load of the member variable from this is something that could cause an access violation: if either this is not a valid pointer (because you incorrectly cast something to a pointer to your class or because prior Undefined Behaviour already trashed your process) or potentially if this was already deleted.

Your intuition was correct that the comparison is unlikely to be a problem (the rare exception being platforms with pointer trap representations) - you were just missing the fact that the pointer had to be loaded from somewhere to be compared.

The Invalid argument exception might be because &formatContext is not a pointer to a pointer to a valid object and as such it is an invalid argument to the avformat_close_input function.
So the exception might come from that function (use a debugger) and not from the nullptr check that should always be valid as you are comparing two pointers (two numbers if the & operator is not overloaded).