It occurs to me that there is something you can do as a type of back door. You say that you have a login method that asks you for credentials and you have to push a button to get in. But that means that there is no password on the DB, there is a password IN the DB - and that makes all the difference in the world. With a password ON the DB, you can't have something run to ask for anything until Access itself determines whether you know the password, and it is a password for the database as a whole for all users. But what you describe isn't like that, so the DB isn't encrypted via password.
Make an new, empty DB of the same type as your problem child - I believe you said it was an .MDB - and open it. Now use the External Data options to copy every element of the miscreant DB (as an input source) to the new, empty DB. Doing so calls up a multi-tab dialog box for which you need to "Select All" for everything it allows with that option. You want to copy EVERYTHING that it allows you to copy. Since this is internal to your machine, it should be a relatively quick operation unless you have a 1 GB database file.
Once the import is complete, you should be able to examine everything in the new copy because at this point you are in Access and inside your app, but the DB technically didn't open. More precisely, the "Opening Menu" Form_Open event routine hasn't run so your safeguards are not active. You can poke around to see if your table definitions and data are intact. You can examine macros, forms, reports, queries, etc. You can look at code, including any modules and event routines.
Now do a Compact & Repair. Since a C&R closes and re-opens the DB, it might prompt you for your login and you could see whether the button works. If it does, your problem was some form of corruption. If not, at least it was a non-destructive test and your original file is still available.