{"id":99795,"date":"2018-09-21T07:00:00","date_gmt":"2018-09-21T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=99795"},"modified":"2019-03-13T00:30:17","modified_gmt":"2019-03-13T07:30:17","slug":"20180921-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180921-00\/?p=99795","title":{"rendered":"Why is regsvr32<\/CODE> exiting with code 3?"},"content":{"rendered":"

A customer had a script to set up a virtual machine, but this call was failing: <\/p>\n

\nregsvr32 \/s \/n \/i:u Awesome.dll\n<\/pre>\n
The DLL failed to register, and regsvr32<\/code> exited with code 3. <\/p>\n
Last time<\/a>, we saw exit code 3 means that the Load­Library<\/code> call failed. The customer reported that the error was not consistent, and they’ve been working around it by waiting a little while and retrying the operation. But sometimes, even after a few retries, the operation still fails. <\/p>\n
The were running regsvr32<\/code> in silent mode, so no error messages were displayed to the user. <\/p>\n
According to the table from last time<\/a>, step 3 is the Load­Library<\/code> step. Since the problem was random and sometimes cleared up after a few retries, this ruled out systematic errors like copying the file to the wrong directory, or copying the wrong version of the file. Those types of errors would result in the operation failing consistently, rather than randomly. <\/p>\n
I suspected that the Load­Library<\/code> failed because the file was still in use, either because it was still being copied to the VM, or because it was being scanned or blocked by anti-malware software running in the VM. <\/p>\n
One option for digging further is to run regsvr32<\/code> one last time in non-silent mode, so that the error details are on the screen. They could write an automation client that scrapes the message before dismissing the dialog box. If they go the automation client route, they may as well always<\/i> run regsvr32<\/code> in non-silent mode. <\/p>\n
If the team doesn’t have experience with writing automation, they could just set a watchdog on regsvr32<\/code>. Pick a generous amount of time to cover typical running time of regsvr32<\/code> in the success cases. If regsvr32<\/code> has not returned by then, then take a screen shot and then terminate the regsvr32<\/code> proces. <\/p>\n
Or they could write their own program that tries to Load­Library<\/code> their DLL and captures the Get­Last­Error<\/code>. Run the custom program once the first regsvr32<\/code> fails. They could even turn on loader snaps<\/a> to get extremely detailed information about the Load­Library<\/code> operation; that information will pinpoint exactly where it went wrong. <\/p>\n
Another option is to run regsvr32<\/code> under the debugger with loader snaps enabled and tell the debugger to log all output to a file. <\/p>\n
\ncdb -Ggx -logo log.txt regsvr32 \/s \/n i:u Awesome.dll\n<\/pre>\n
If the DLL registers successfully, then delete the log file. If it fails, then save the log file somewhere for analysis. <\/p>\n
Yet another possibility is that the exit code of 3 is a red herring. Perhaps something went wrong in a way that led to the C runtime calling the abort()<\/code> function, which exits the program with code 3<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"
Coming up with theories and ways to test those theories.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[104],"class_list":["post-99795","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-tipssupport"],"acf":[],"blog_post_summary":"
Coming up with theories and ways to test those theories.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/99795","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=99795"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/99795\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=99795"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=99795"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=99795"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}