Another Windows server was hosting both the development/test environments for the same RDBMS combination, ie. 11.2.0.4 and 12.1.0.1 running together.
On this server both database versions co-existed without any issues.
Similar to dev/test a fourth Windows server was supposed host both a 11.2.0.4 and a 12.1.0.1 Oracle Data Guard Physical Standby database, one for each productive database.

The 12.1.0.1 Physical Standby database was created and instantiated first, everything running nice and smooth.
Then the 11.2.0.4 Physical Standby database was cloned/instantiated from its primary database.
When starting the cloned 11.2.0.4 standby database instance (in MOUNT state) and starting REDO APPLY the following error occurred:

ORA-07445: exception encountered: core dump [PC:0x2223829] [ACCESS_VIOLATION] [ADDR:0x7FFFFFFF8] [PC:0x2223829] [UNABLE_TO_READ] []


And REDO APPLY is not starting, the standby database is not getting in sync with its primary database.
The suspiscion falls on security issues, e.g. Windows ACLs, Oracle RDBMS Software ownership, Windows Service Logon-account etc.
But in the end this issue turned out to be a BUG!

Bug 17535265: ORA-7445 ERRORS IN DATA GUARD STANDBY DATABASE AFTER 12C INSTALLATION

The problem is that the 12c RDBMS installation creates various local Windows groups, for example ORA_OPER.
And the user account, which owns/controls the 11.2.0.4 software and database instance, is not added automatically and therefore the sysoper connection fails with the ORA-07445 error.

The work-around is simply to add the user account, which owns/controls the 11.2.0.4 standby database, to the ORA_OPER group.
After this the ORA-07445 error disappeared and REDO APPLY worked without any issues.
See MOS article 1591821.1 “ORA-7445 Errors In Data Guard Standby Database” as well as bug information for further information.