This situation sounds a lot like a post I answered two years ago (InnoDB table SELECT returns ERROR 2006 (HY000): MySQL server has gone away (after power outage))
First, here is the InnoDB Architecture
In that post, I basically point out that the metadata of the table is still present inside the system tablespace file ibdata1.
When you ran
SHOW TABLES;, all mysqld did was report the
.frm files. It is possible to create the table as MyISAM because it has no attachments to ibdata1 or any other metadata. Yet, you cannot convert it to InnoDB because the metadata somehow imagines that the
.frm and some tablespace_id is attached to the table name. Based on my old post, I would just mysqldump all the other tables and call you table a lost cause. However, Percona has the Data Recovery Toolkit for just such an occasion.
In the webpage about the Data Recovery Toolkit says
The Percona Data Recovery Tool for InnoDB is a free toolkit for recovering lost or corrupted data from InnoDB tables. It provides a way to extract InnoDB's data from files or raw devices in a tab-separated format when standard InnoDB recovery cannot be used for some reason such as a dropped table or severe corruption that prevents InnoDB from recognizing the data. It can be used for MySQL recovery to retrieve deleted tables, recover previous versions of updated rows, or fix InnoDB file corruption after a hardware failure such as a memory fault or bad cabling.
Percona has used these tools to perform MySQL data recovery for many customers, including extremely large datasets. Although the tools are powerful, performing InnoDB data recovery correctly requires expert knowledge of the InnoDB storage format and source code plus experience, and intuition. Percona can help with our data recovery service.
I have not used it, but if Percona made it, you should give it a try.
If you have a backup of that lost table (in the form of a mysqldump), you should carry out the steps from my old post and then load the backup of the lost table.
Once you get this situation squared away, you should tune InnoDB to flush changes to disk.
That way, when you shutdown mysql, InnoDB can more thoroughly flush changes.
If you want even better assurance of InnoDB being flushed to disk, you should use MySQL in Linux.