If you initialize both env_logger and eventlog in the same process it will crash, and you'll waste a bunch of time looking for the problem in the wrong place.
Ironically you'll think "If only the logging worked, then I could easily track this down", while the hint is, clearly, that you're not seeing any logs. 
If you set RUST_BACKTRACE=1 the panic message will include a backtrace pointing to the exact line that triggered the panic.
In this case, env_logger::init() explicitly says it'll crash if you've initialized another global logger:
(you can use the env_logger::try_init() function for a non-crashing version)
Unfortunately stdout/stderr do not exist in a Windows service context, so that would be of limited use -- unless there's a way to dump them directly to a file?
Hm. Now that you mention it, RUST_BACKTRACE should be made to be able to output using OutputDebugString().
Oh, I figured it was a bad idea, I just hadn't done it before so I didn't know it would crash. I have service:ified two other daemons the past weeks and carefully avoided initializing both loggers simultaneously. The issue was basically sloppy copy/paste:
fn main() {
// .. logging was initialized here ..
#[cfg(windows)]
if args.run_as_service {
// This function initializes eventlog..
service::win::run(args)?;
return Ok(());
}
// .. while it should have bee initialized here ..
}
.. and it didn't occur to me to look in main(), because obviously I wouldn't be initializing env_logger before kicking off the service. ... cough, cough. 
This experience has reminded me that I need to find out how complicated it is to do remote debugging of Rust applications in a Windows environment. Services are just so much easier to deal with using a remote debugger.