Okay. I posted a report at wxWidgets bug track system:
https://trac.wxwidgets.org/ticket/18925#ticketHowever, I am not sure this is a problem of wx, still less this will trigger their investigation.
As for C::B, I think it may need an alternative mechanism of specifying a font (e.g. an input box for font properties or a convenient way to edit the relevant item(s) in the configuration file(s)), so when one method fails the other will come to rescue.
Just take the wx font sample program as an example. Besides calling the system's font dialog, it allows direct input of font name, size, etc. in its edit boxes. While enumerating fonts may cause problems in some extreme cases, direct input will never.
Another example is Double Commander, its font configuration page looks like: (attached pic). Next to the "select font" button there are edit boxes for font name and size. When pushing the button fails (This occurs sometimes for me), the user can still use the edit boxes.
And there are many other apps which allow the user to specify fonts by editing their configuration files.
Since C::B is now relying solely on the font selection dialog, I have to live with an unpleasant font before the issue gets solved.