It’s highly unlikely you have a conflict between 32 and 64 bits as 32 bit Toad (Is there such a thing?) will not be able to load or use the 64 bit DLLs etc, while 64 bit Toad will not be able to use the 32 bit DLLs etc. This also applies to Oracle clients, if you have 64 bit Toad it cannot use the 32 bit Oracle client software and vice versa with 32 bit Toad.
It might be helpful to the developers if you posted the details of the access violation, things like what it says, can it be reproduced, what were you doing at the time. There may also be a diagnostics file created - go to Help -> Support Bundle and see if the dump data matches up with your situation.
One thing to beware of, if you have 32 bit Oracle client and 32 bit Toad running on a 64 bit Windows OS, then from Windows 7 onwards, there is a tendency for 32 bit “stuff” to be installed in “c:\program files (x86)\blah”. Oracle does not like running from a folder with either ‘(’ or ‘)’ in its name.
In the support bundle details, scroll down to the section “ORACLE HOMES DATA” and check that all the “ORACLE_HOME” entries are outside this infernal ‘(x86)’ folder. It’s NOT a problem to have “inst_loc” pointing at this faulty folder, yo just need the various ORACLE_HOMEs to be well away from that location.
In fact, if you ever use SQL*Plus and runs scripts from withing the ORACLE_HOME, then also avoid having a space in the path to the ORACLE_HOME as none of your scripts will run very well! (Ask me how I found out!)
Make sure that all your ORACLE_HOMEs are valid and on the PATH. This is also detailed in the support bundle section you are looking at.