It's a configuration.
There is only one strategy for dealing with this, make your application use one known format for any string representation of date / time / number / decimal that is logic dependant.
It's the only way to be sure your code is going to work, everywhere it needs to.
Tracking down exactly where this is going wrong, might turn ot to be easy, it could be a major pain in the arse. Once you've done it you solved one configuration. There are hundreds of others.
A little story to illustrate, winodws xp box set up as full english UK.
One bit of code was saying it couldn't find any records for a date 3/6/yyyy
This piece of code was usng an API routine with the date passed as a variant. It was looking for 6/3/yyyy
That particular routine always took any ambiguous date as being in the format mm/dd/yyyy. It did not respect regional settings, application settings, in fact any configuration. So it only failed from 1-12 / 1 - 12 / where date didnt equal the month. Took support and then me three remote support calls to identify the actual issue, another two hours to track it down (we couldn't replicate it, different dll on our systems)
and exactly five minutes to fix the code, but the customer had to wait two months for the patch in the next release.
Go unambiguous, it's the only way to be sure now and in the future.
If you are curious enough to want to know.
Wrap that CDate call with an on error goto, display the string it failed to convert and then do a graceful fail.
Personally I'd just fix the problem instead of the symptom though.