bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Mohammed Imaduddin Humayun]

When netlogon service is running in the background on Windows (Win
7 here) in a networked domain (e.g. a pc/laptop on a university domain)
starting Emacs usually fails or is miserably slow  although the 
emacs.exe process
  can be seen running in the background. Tried running with -Q, 
-no-init-file,
text mode only and several other options to no avail.

Bug might also be difficult to reproduce. However, the issue is also 
reported by other users here:
(1) http://www.hydrus.org.uk/journal/emacs-netlogon.html
(2) 
http://stackoverflow.com/questions/2007329/emacs-23-1-50-1-hangs-ramdomly-for-6-8-seconds-on-windows-xp

This mostly seems to occur when emacs is used in an environment where the
network changes frequently (e.g. using laptop at work network
then  home network etc.). Can confirm that Emacs runs just fine when the 
netlogon service is stopped,
but this is more of a stopgap measure than a solution. At the very
least this needs to be classified officially as a bug and the workaround
made more visible.



In GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601)
  of 2012-08-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
  `configure --with-gcc (4.6) --cflags
  -ID:/devel/emacs/libs/libXpm-3.5.8/include
  -ID:/devel/emacs/libs/libXpm-3.5.8/src
  -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
  -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
  -ID:/devel/emacs/libs/giflib-4.1.4-1/include
  -ID:/devel/emacs/libs/jpeg-6b-4/include
  -ID:/devel/emacs/libs/tiff-3.8.2-1/include
  -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: ENU
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8
   default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
   diff-auto-refine-mode: t
   nxhtml-menu-mode: t
   nxhtml-tag-do-also: t
   popcmp-group-alternatives: t
   popcmp-short-help-beside-alts: t
   shell-dirtrack-mode: t
   mlinks-active-links: t
   rngalt-minimal-validation-header: t
   rngalt-display-validation-header: t
   predictive-which-dict-mode: t
   global-auto-revert-mode: t
   show-paren-mode: t
   delete-selection-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
M-x b u g <tab> <tab> <M-backspace> <M-backspace> r
e p o <tab> r t - e m <tab> - q <tab> <return> n e
t l o g o n SPC <backspace> <return> <help-echo> <help-echo>
<help-echo> <down> <down> <down> <down> <return> <right>
<return> <left> <down> <down> <down> <up> <tab> C-a
<return> SPC C-x k <return> M-x r e p o <tab> r t <tab>
<return>

Recent messages:
Loading c:/Users/humayun/.emacs.d/nxhtml/autostart.el (source)...done
Finding all versions of R on your system...
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list... [2 times]
Contacting host: debbugs.gnu.org:80
Reporting new bug! [2 times]
byte-code: End of buffer [2 times]
Reporting new bug!
call-interactively: Buffer is read-only: #<buffer *Existing Emacs Bugs*>
Making completion list...

Load-path shadows:
c:/Users/humayun/.emacs.d/nxhtml/util/ack hides ~/.emacs.d/nav/ack
c:/Users/humayun/.emacs.d/nxhtml/util/org-odt hides c:/Emacs 
24.2/site-lisp/org/org-odt
c:/Emacs 24.2/site-lisp/org/org hides c:/Emacs 24.2/lisp/org/org
c:/Emacs 24.2/site-lisp/org/org-xoxo hides c:/Emacs 24.2/lisp/org/org-xoxo
c:/Emacs 24.2/site-lisp/org/org-wl hides c:/Emacs 24.2/lisp/org/org-wl
c:/Emacs 24.2/site-lisp/org/org-w3m hides c:/Emacs 24.2/lisp/org/org-w3m
c:/Emacs 24.2/site-lisp/org/org-vm hides c:/Emacs 24.2/lisp/org/org-vm
c:/Emacs 24.2/site-lisp/org/org-timer hides c:/Emacs 24.2/lisp/org/org-timer
c:/Emacs 24.2/site-lisp/org/org-taskjuggler hides c:/Emacs 
24.2/lisp/org/org-taskjuggler
c:/Emacs 24.2/site-lisp/org/org-table hides c:/Emacs 24.2/lisp/org/org-table
c:/Emacs 24.2/site-lisp/org/org-src hides c:/Emacs 24.2/lisp/org/org-src
c:/Emacs 24.2/site-lisp/org/org-special-blocks hides c:/Emacs 
24.2/lisp/org/org-special-blocks
c:/Emacs 24.2/site-lisp/org/org-rmail hides c:/Emacs 24.2/lisp/org/org-rmail
c:/Emacs 24.2/site-lisp/org/org-remember hides c:/Emacs 
24.2/lisp/org/org-remember
c:/Emacs 24.2/site-lisp/org/org-publish hides c:/Emacs 
24.2/lisp/org/org-publish
c:/Emacs 24.2/site-lisp/org/org-protocol hides c:/Emacs 
24.2/lisp/org/org-protocol
c:/Emacs 24.2/site-lisp/org/org-plot hides c:/Emacs 24.2/lisp/org/org-plot
c:/Emacs 24.2/site-lisp/org/org-pcomplete hides c:/Emacs 
24.2/lisp/org/org-pcomplete
c:/Users/humayun/.emacs.d/nxhtml/util/org-odt hides c:/Emacs 
24.2/lisp/org/org-odt
c:/Emacs 24.2/site-lisp/org/org-mouse hides c:/Emacs 24.2/lisp/org/org-mouse
c:/Emacs 24.2/site-lisp/org/org-mobile hides c:/Emacs 
24.2/lisp/org/org-mobile
c:/Emacs 24.2/site-lisp/org/org-mks hides c:/Emacs 24.2/lisp/org/org-mks
c:/Emacs 24.2/site-lisp/org/org-mhe hides c:/Emacs 24.2/lisp/org/org-mhe
c:/Emacs 24.2/site-lisp/org/org-mew hides c:/Emacs 24.2/lisp/org/org-mew
c:/Emacs 24.2/site-lisp/org/org-macs hides c:/Emacs 24.2/lisp/org/org-macs
c:/Emacs 24.2/site-lisp/org/org-mac-message hides c:/Emacs 
24.2/lisp/org/org-mac-message
c:/Emacs 24.2/site-lisp/org/org-lparse hides c:/Emacs 
24.2/lisp/org/org-lparse
c:/Emacs 24.2/site-lisp/org/org-list hides c:/Emacs 24.2/lisp/org/org-list
c:/Emacs 24.2/site-lisp/org/org-latex hides c:/Emacs 24.2/lisp/org/org-latex
c:/Emacs 24.2/site-lisp/org/org-jsinfo hides c:/Emacs 
24.2/lisp/org/org-jsinfo
c:/Emacs 24.2/site-lisp/org/org-irc hides c:/Emacs 24.2/lisp/org/org-irc
c:/Emacs 24.2/site-lisp/org/org-install hides c:/Emacs 
24.2/lisp/org/org-install
c:/Emacs 24.2/site-lisp/org/org-inlinetask hides c:/Emacs 
24.2/lisp/org/org-inlinetask
c:/Emacs 24.2/site-lisp/org/org-info hides c:/Emacs 24.2/lisp/org/org-info
c:/Emacs 24.2/site-lisp/org/org-indent hides c:/Emacs 
24.2/lisp/org/org-indent
c:/Emacs 24.2/site-lisp/org/org-id hides c:/Emacs 24.2/lisp/org/org-id
c:/Emacs 24.2/site-lisp/org/org-icalendar hides c:/Emacs 
24.2/lisp/org/org-icalendar
c:/Emacs 24.2/site-lisp/org/org-html hides c:/Emacs 24.2/lisp/org/org-html
c:/Emacs 24.2/site-lisp/org/org-habit hides c:/Emacs 24.2/lisp/org/org-habit
c:/Emacs 24.2/site-lisp/org/org-gnus hides c:/Emacs 24.2/lisp/org/org-gnus
c:/Emacs 24.2/site-lisp/org/org-freemind hides c:/Emacs 
24.2/lisp/org/org-freemind
c:/Emacs 24.2/site-lisp/org/org-footnote hides c:/Emacs 
24.2/lisp/org/org-footnote
c:/Emacs 24.2/site-lisp/org/org-feed hides c:/Emacs 24.2/lisp/org/org-feed
c:/Emacs 24.2/site-lisp/org/org-faces hides c:/Emacs 24.2/lisp/org/org-faces
c:/Emacs 24.2/site-lisp/org/org-exp hides c:/Emacs 24.2/lisp/org/org-exp
c:/Emacs 24.2/site-lisp/org/org-exp-blocks hides c:/Emacs 
24.2/lisp/org/org-exp-blocks
c:/Emacs 24.2/site-lisp/org/org-eshell hides c:/Emacs 
24.2/lisp/org/org-eshell
c:/Emacs 24.2/site-lisp/org/org-entities hides c:/Emacs 
24.2/lisp/org/org-entities
c:/Emacs 24.2/site-lisp/org/org-docview hides c:/Emacs 
24.2/lisp/org/org-docview
c:/Emacs 24.2/site-lisp/org/org-docbook hides c:/Emacs 
24.2/lisp/org/org-docbook
c:/Emacs 24.2/site-lisp/org/org-datetree hides c:/Emacs 
24.2/lisp/org/org-datetree
c:/Emacs 24.2/site-lisp/org/org-ctags hides c:/Emacs 24.2/lisp/org/org-ctags
c:/Emacs 24.2/site-lisp/org/org-crypt hides c:/Emacs 24.2/lisp/org/org-crypt
c:/Emacs 24.2/site-lisp/org/org-compat hides c:/Emacs 
24.2/lisp/org/org-compat
c:/Emacs 24.2/site-lisp/org/org-colview hides c:/Emacs 
24.2/lisp/org/org-colview
c:/Emacs 24.2/site-lisp/org/org-clock hides c:/Emacs 24.2/lisp/org/org-clock
c:/Emacs 24.2/site-lisp/org/org-capture hides c:/Emacs 
24.2/lisp/org/org-capture
c:/Emacs 24.2/site-lisp/org/org-bibtex hides c:/Emacs 
24.2/lisp/org/org-bibtex
c:/Emacs 24.2/site-lisp/org/org-beamer hides c:/Emacs 
24.2/lisp/org/org-beamer
c:/Emacs 24.2/site-lisp/org/org-bbdb hides c:/Emacs 24.2/lisp/org/org-bbdb
c:/Emacs 24.2/site-lisp/org/org-attach hides c:/Emacs 
24.2/lisp/org/org-attach
c:/Emacs 24.2/site-lisp/org/org-ascii hides c:/Emacs 24.2/lisp/org/org-ascii
c:/Emacs 24.2/site-lisp/org/org-archive hides c:/Emacs 
24.2/lisp/org/org-archive
c:/Emacs 24.2/site-lisp/org/org-agenda hides c:/Emacs 
24.2/lisp/org/org-agenda
c:/Emacs 24.2/site-lisp/org/ob hides c:/Emacs 24.2/lisp/org/ob
c:/Emacs 24.2/site-lisp/org/ob-tangle hides c:/Emacs 24.2/lisp/org/ob-tangle
c:/Emacs 24.2/site-lisp/org/ob-table hides c:/Emacs 24.2/lisp/org/ob-table
c:/Emacs 24.2/site-lisp/org/ob-sqlite hides c:/Emacs 24.2/lisp/org/ob-sqlite
c:/Emacs 24.2/site-lisp/org/ob-sql hides c:/Emacs 24.2/lisp/org/ob-sql
c:/Emacs 24.2/site-lisp/org/ob-shen hides c:/Emacs 24.2/lisp/org/ob-shen
c:/Emacs 24.2/site-lisp/org/ob-sh hides c:/Emacs 24.2/lisp/org/ob-sh
c:/Emacs 24.2/site-lisp/org/ob-screen hides c:/Emacs 24.2/lisp/org/ob-screen
c:/Emacs 24.2/site-lisp/org/ob-scheme hides c:/Emacs 24.2/lisp/org/ob-scheme
c:/Emacs 24.2/site-lisp/org/ob-sass hides c:/Emacs 24.2/lisp/org/ob-sass
c:/Emacs 24.2/site-lisp/org/ob-ruby hides c:/Emacs 24.2/lisp/org/ob-ruby
c:/Emacs 24.2/site-lisp/org/ob-ref hides c:/Emacs 24.2/lisp/org/ob-ref
c:/Emacs 24.2/site-lisp/org/ob-R hides c:/Emacs 24.2/lisp/org/ob-R
c:/Emacs 24.2/site-lisp/org/ob-python hides c:/Emacs 24.2/lisp/org/ob-python
c:/Emacs 24.2/site-lisp/org/ob-plantuml hides c:/Emacs 
24.2/lisp/org/ob-plantuml
c:/Emacs 24.2/site-lisp/org/ob-picolisp hides c:/Emacs 
24.2/lisp/org/ob-picolisp
c:/Emacs 24.2/site-lisp/org/ob-perl hides c:/Emacs 24.2/lisp/org/ob-perl
c:/Emacs 24.2/site-lisp/org/ob-org hides c:/Emacs 24.2/lisp/org/ob-org
c:/Emacs 24.2/site-lisp/org/ob-octave hides c:/Emacs 24.2/lisp/org/ob-octave
c:/Emacs 24.2/site-lisp/org/ob-ocaml hides c:/Emacs 24.2/lisp/org/ob-ocaml
c:/Emacs 24.2/site-lisp/org/ob-mscgen hides c:/Emacs 24.2/lisp/org/ob-mscgen
c:/Emacs 24.2/site-lisp/org/ob-maxima hides c:/Emacs 24.2/lisp/org/ob-maxima
c:/Emacs 24.2/site-lisp/org/ob-matlab hides c:/Emacs 24.2/lisp/org/ob-matlab
c:/Emacs 24.2/site-lisp/org/ob-lob hides c:/Emacs 24.2/lisp/org/ob-lob
c:/Emacs 24.2/site-lisp/org/ob-lisp hides c:/Emacs 24.2/lisp/org/ob-lisp
c:/Emacs 24.2/site-lisp/org/ob-lilypond hides c:/Emacs 
24.2/lisp/org/ob-lilypond
c:/Emacs 24.2/site-lisp/org/ob-ledger hides c:/Emacs 24.2/lisp/org/ob-ledger
c:/Emacs 24.2/site-lisp/org/ob-latex hides c:/Emacs 24.2/lisp/org/ob-latex
c:/Emacs 24.2/site-lisp/org/ob-keys hides c:/Emacs 24.2/lisp/org/ob-keys
c:/Emacs 24.2/site-lisp/org/ob-js hides c:/Emacs 24.2/lisp/org/ob-js
c:/Emacs 24.2/site-lisp/org/ob-java hides c:/Emacs 24.2/lisp/org/ob-java
c:/Emacs 24.2/site-lisp/org/ob-haskell hides c:/Emacs 
24.2/lisp/org/ob-haskell
c:/Emacs 24.2/site-lisp/org/ob-gnuplot hides c:/Emacs 
24.2/lisp/org/ob-gnuplot
c:/Emacs 24.2/site-lisp/org/ob-fortran hides c:/Emacs 
24.2/lisp/org/ob-fortran
c:/Emacs 24.2/site-lisp/org/ob-exp hides c:/Emacs 24.2/lisp/org/ob-exp
c:/Emacs 24.2/site-lisp/org/ob-eval hides c:/Emacs 24.2/lisp/org/ob-eval
c:/Emacs 24.2/site-lisp/org/ob-emacs-lisp hides c:/Emacs 
24.2/lisp/org/ob-emacs-lisp
c:/Emacs 24.2/site-lisp/org/ob-dot hides c:/Emacs 24.2/lisp/org/ob-dot
c:/Emacs 24.2/site-lisp/org/ob-ditaa hides c:/Emacs 24.2/lisp/org/ob-ditaa
c:/Emacs 24.2/site-lisp/org/ob-css hides c:/Emacs 24.2/lisp/org/ob-css
c:/Emacs 24.2/site-lisp/org/ob-comint hides c:/Emacs 24.2/lisp/org/ob-comint
c:/Emacs 24.2/site-lisp/org/ob-clojure hides c:/Emacs 
24.2/lisp/org/ob-clojure
c:/Emacs 24.2/site-lisp/org/ob-calc hides c:/Emacs 24.2/lisp/org/ob-calc
c:/Emacs 24.2/site-lisp/org/ob-C hides c:/Emacs 24.2/lisp/org/ob-C
c:/Emacs 24.2/site-lisp/org/ob-awk hides c:/Emacs 24.2/lisp/org/ob-awk
c:/Emacs 24.2/site-lisp/org/ob-asymptote hides c:/Emacs 
24.2/lisp/org/ob-asymptote
~/.emacs.d/predictive/avl-tree hides c:/Emacs 24.2/lisp/emacs-lisp/avl-tree

Features:
(shadow sort mail-extr network-stream starttls url-cache emacsbug
message rfc822 mml mml-sec mailabbrev gmm-utils mailheader sendmail
csv-mode-autoloads package tabulated-list psvn log-edit pcvs-util
add-log diff-mode elp org-install ess-eldoc ess-toolbar ess-mouse
mouseme thingatpt browse-url ess-menu ess-swv ess-noweb
ess-noweb-font-lock-mode ess-bugs-l essd-els ess-sas-d ess-sas-l
ess-sas-a ess-arc-d ess-vst-d ess-xls-d ess-lsp-l ess-sta-d ess-sta-l
make-regexp ess-sp6w-d ess-sp4-d ess-sp3-d ess-julia ess-r-d
ess-tracebug ess-roxy ess-help ess-developer ess-r-args eldoc ess-s-l
ess ess-inf newcomment ess-mode ess-noweb-mode ess-utils ess-custom
executable ess-compat ess-site htmlize-view w32-winprint htmlize
flymake-files flymakemsg nxhtml-autostart nxhtml-autoload moz majmodpri
nxhtml-menu udev-rinari udev-ecb udev flymake css-color nxhtml-mode
html-quote tidy-xhtml ediff-merg ediff-diff ediff-wind ediff-help
ediff-util ediff-mult ediff-init ediff html-imenu imenu loadhist popcmp
xhtml-help html-toc xml fupd html-pagetoc appmenu-fold fold-dwim
tex-mode shell inlimg html-write mlinks appmenu mumamo sgml-mode
ruby-mode rngalt rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse
rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln
nxml-rap nxml-util nxml-glyph nxml-enc xmltok mumamo-cmirr desktop
cc-engine cc-vars cc-defs help-mode view flyspell html-upl html-site
ourcomments-util uniquify recentf tree-widget mm-url gnus gnus-ems
nnheader mail-utils org warnings ob-tangle ob-ref ob-lob ob-table
org-footnote org-src ob-comint ob-keys org-pcomplete pcomplete org-list
org-faces org-entities ob-emacs-lisp ob org-compat org-macs ob-eval
format-spec find-func cal-menu calendar cal-loaddefs ido bookmark pp
apropos grep ffip gimpedit foldit noutline outline hideshow web-vcs
derived rx url-http tls url url-proxy url-privacy url-expand url-methods
url-history mailcap url-auth url-cookie url-util url-parse auth-source
assoc gnus-util password-cache url-gw url-vars mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr cus-edit cus-start cus-load wid-edit web-autoload nxhtml-base
easy-mmode nav dired ack compile comint regexp-opt ansi-color ring
predictive-html auto-overlay-flat predictive-texinfo predictive-latex
predictive-auto-overlay-auto-dict auto-overlay-nested auto-overlay-self
auto-overlay-line auto-overlay-word predictive timerfunctions
auto-overlays auto-overlay-common dict-tree trie advice help-fns
advice-preload tNFA queue heap avl-tree semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw eieio
byte-opt bytecomp byte-compile cconv macroexp mode-local cedet
completion-ui-sources completion-ui-menu pos-tip completion-ui-tooltip
completion-ui-echo completion-ui-hotkeys completion-ui-dynamic
completion-ui-popup-frame completion-ui rw-hunspell rw-ispell ispell
rw-language-and-country-codes reftex reftex-vars easymenu tex-mik
preview-latex tex-site auto-loads edmacro kmacro autorevert
solarized-light-theme solarized-definitions cl paren delsel time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table
ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> Date: Sat, 06 Oct 2012 12:05:47 +0200
> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> 
> When netlogon service is running in the background on Windows (Win
> 7 here) in a networked domain (e.g. a pc/laptop on a university domain)
> starting Emacs usually fails or is miserably slow  although the 
> emacs.exe process

What's your value of w32-get-true-file-attributes?  Can you try
setting it in turn to each one of the 3 possible values, and see if
that helps?

If you can run Emacs under a debugger, I could ask you to check out
some more things.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Mohammed Imaduddin Humayun]

On 10/6/2012 7:40 PM, Eli Zaretskii wrote:
>> Date: Sat, 06 Oct 2012 12:05:47 +0200
>> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
>>
>> When netlogon service is running in the background on Windows (Win
>> 7 here) in a networked domain (e.g. a pc/laptop on a university domain)
>> starting Emacs usually fails or is miserably slow  although the
>> emacs.exe process
> What's your value of w32-get-true-file-attributes?  Can you try
> setting it in turn to each one of the 3 possible values, and see if
> that helps?
>
> If you can run Emacs under a debugger, I could ask you to check out
> some more things.
w32-get-true-file attributes is set to nil in my case. I tried setting 
it to local, non-nil and nil in turn with the following results:
(i) with netlogon service - delayed Emacs startup as reported in the bug 
for each of the values
(ii) without netlogon service - Emacs starts instantly in all cases

I use the binary build which probably isn't meant for debugging. Also my 
experience in using gdb is limited, but if provided with a debug build 
and instructions on what to do, I can at least attempt.

PS: A short screencast of the problem can be viewed here if it helps - 
http://youtu.be/G36HpkVt8i4

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> Date: Sun, 07 Oct 2012 12:12:26 +0200
> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> On 10/6/2012 7:40 PM, Eli Zaretskii wrote:
> >> Date: Sat, 06 Oct 2012 12:05:47 +0200
> >> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> >>
> >> When netlogon service is running in the background on Windows (Win
> >> 7 here) in a networked domain (e.g. a pc/laptop on a university domain)
> >> starting Emacs usually fails or is miserably slow  although the
> >> emacs.exe process
> > What's your value of w32-get-true-file-attributes?  Can you try
> > setting it in turn to each one of the 3 possible values, and see if
> > that helps?
> >
> > If you can run Emacs under a debugger, I could ask you to check out
> > some more things.
> w32-get-true-file attributes is set to nil in my case. I tried setting 
> it to local, non-nil and nil in turn with the following results:
> (i) with netlogon service - delayed Emacs startup as reported in the bug 
> for each of the values
> (ii) without netlogon service - Emacs starts instantly in all cases

After Emacs starts, do you see slowdown in file operations, like
"C-x d" (Dired) for networked directories on the domain for which the
netlogon service runs?  Or is the slowdown limited to the startup?

Also, your original report says "starting Emacs fails or is miserably
slow".  When it fails, what message(s) do you see to the effect of the
failure?  And when it is slow, how much time does it take for Emacs to
eventually come up?

> I use the binary build which probably isn't meant for debugging. Also my 
> experience in using gdb is limited, but if provided with a debug build 
> and instructions on what to do, I can at least attempt.

Debug builds of the recent development snapshots are available from
here:

    http://alpha.gnu.org/gnu/emacs/windows/

First, please see if the same slow startup happens with the latest
snapshot.  If it does, I will give you instructions on what to do to
investigate.

Thanks.

> PS: A short screencast of the problem can be viewed here if it helps - 
> http://youtu.be/G36HpkVt8i4

Does the same happen if you start emacs.exe directly from the cmd
prompt, instead of clicking on runemacs.exe?

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Mohammed Imaduddin Humayun]

On 10/7/2012 1:02 PM, Eli Zaretskii wrote:
>> Date: Sun, 07 Oct 2012 12:12:26 +0200
>> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
>> CC: Eli Zaretskii <eliz@gnu.org>
>>
>> w32-get-true-file attributes is set to nil in my case. I tried setting
>> it to local, non-nil and nil in turn with the following results:
>> (i) with netlogon service - delayed Emacs startup as reported in the bug
>> for each of the values
>> (ii) without netlogon service - Emacs starts instantly in all cases
> After Emacs starts, do you see slowdown in file operations, like
> "C-x d" (Dired) for networked directories on the domain for which the
> netlogon service runs?  Or is the slowdown limited to the startup?
>
> Also, your original report says "starting Emacs fails or is miserably
> slow".  When it fails, what message(s) do you see to the effect of the
> failure?  And when it is slow, how much time does it take for Emacs to
> eventually come up?
Below is roughly the order of events after starting Emacs when netlogon 
is running:
- 2~3 min - GUI shows up, Emacs welcome screen (*GNU Emacs*) is not 
loaded yet. Window elements (menus etc.) are unresponsive.
- 6~7 min - Welcome screen shows up. Commands can now be run, GUI is 
responsive.
- Post startup, if w32-get-true-file-attributes is:
         (a) nil:  file operations are responsive albeit 3-4x slower 
than when netlogon is not running i.e. not instantaneous.
         (b) default: extremely sluggish response. File operations 
(opening of files, filename autocomplete or dired etc.) each take 2-3 
minutes or more.

By startup failure I imply the performance is so slow and unpredictable, 
one is unsure if Emacs will actually show up. No error message is 
displayed as such. I'm actually out of patience by this time.

>> I use the binary build which probably isn't meant for debugging. Also my
>> experience in using gdb is limited, but if provided with a debug build
>> and instructions on what to do, I can at least attempt.
> Debug builds of the recent development snapshots are available from
> here:
>
>      http://alpha.gnu.org/gnu/emacs/windows/
>
> First, please see if the same slow startup happens with the latest
> snapshot.  If it does, I will give you instructions on what to do to
> investigate.
>
> Thanks
Yes, the same problem occurs with the latest alpha build 
'emacs-20120917-r110062'.

>> PS: A short screencast of the problem can be viewed here if it helps -
>> http://youtu.be/G36HpkVt8i4
> Does the same happen if you start emacs.exe directly from the cmd
> prompt, instead of clicking on runemacs.exe?
Yes.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> Date: Mon, 08 Oct 2012 10:49:48 +0200
> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> - Post startup, if w32-get-true-file-attributes is:
>          (a) nil:  file operations are responsive albeit 3-4x slower 
> than when netlogon is not running i.e. not instantaneous.
>          (b) default: extremely sluggish response. File operations 
> (opening of files, filename autocomplete or dired etc.) each take 2-3 
> minutes or more.

Is this with the latest development snapshot?  If not, please try with
that, a lot has changed in that area lately.

Also, what happens when w32-get-true-file-attributes is set to t?  Is
the behavior closer to the default value or to nil?

> >      http://alpha.gnu.org/gnu/emacs/windows/
> >
> > First, please see if the same slow startup happens with the latest
> > snapshot.  If it does, I will give you instructions on what to do to
> > investigate.
> >
> > Thanks
> Yes, the same problem occurs with the latest alpha build 
> 'emacs-20120917-r110062'.

OK.  If you don't already have GDB for Windows, please install it
from here:

  http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/GDB-7.5/

(If you are not an experienced MinGW user, you might be better off
installing GDB with mingw-get utility, which is mentioned on the above
page, because mingw-get will automatically install any dependencies
needed by GDB.)

Once GDB is installed, please follow these steps:

  . Invoke Emacs

  . Use the Task Manager or some equivalent to find out the process ID
    of emacs.exe (not of runemacs.exe!), which is a number.  Since you
    say the startup takes minutes, it shouldn't be a problem to do
    this and the next step while Emacs is still stuck in whatever it's
    doing at this stage.

  . Type from the cmd prompt "gdb -p PID" where PID is the process ID
    of emacs.exe, and hit Enter.  GDB will attach to the running
    Emacs, stop it wherever it is, and show its prompt "(gdb)".

  . Type at GDB's prompt "thread apply all backtrace", and post here
    everything that GDB reports in response.

  . If you can, try these steps both before and after the welcome
    screen comes up, because it's possible that there's more than one
    place that is holding the startup.

Thanks.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Mohammed Imaduddin Humayun]

On 10/8/2012 11:15 AM, Eli Zaretskii wrote:
>
> Is this with the latest development snapshot?  If not, please try with
> that, a lot has changed in that area lately.
>
> Also, what happens when w32-get-true-file-attributes is set to t?  Is
> the behavior closer to the default value or to nil?
Yes, it uses the latest alpha build.
When the atrribute's set to t, the behaviour's closer to default or in 
other words slow.

> OK.  If you don't already have GDB for Windows, please install it
> from here:
>
>    http://sourceforge.net/projects/mingw/files/MinGW/Extension/gdb/GDB-7.5/
>
> (If you are not an experienced MinGW user, you might be better off
> installing GDB with mingw-get utility, which is mentioned on the above
> page, because mingw-get will automatically install any dependencies
> needed by GDB.)
>
> Once GDB is installed, please follow these steps:
>
>    . Invoke Emacs
>
>    . Use the Task Manager or some equivalent to find out the process ID
>      of emacs.exe (not of runemacs.exe!), which is a number.  Since you
>      say the startup takes minutes, it shouldn't be a problem to do
>      this and the next step while Emacs is still stuck in whatever it's
>      doing at this stage.
>
>    . Type from the cmd prompt "gdb -p PID" where PID is the process ID
>      of emacs.exe, and hit Enter.  GDB will attach to the running
>      Emacs, stop it wherever it is, and show its prompt "(gdb)".
>
>    . Type at GDB's prompt "thread apply all backtrace", and post here
>      everything that GDB reports in response.
>
>    . If you can, try these steps both before and after the welcome
>      screen comes up, because it's possible that there's more than one
>      place that is holding the startup.
>
> Thanks.

GDB LOGS
(FYI ,  w32-get-true-file-attribute is default here, but changing this 
does not affect the startup time as mentioned earlier )
========================
Before Welcome Screen
=======================

Thread 3 (Thread 6444.0x212c):
#0  0x77d3000d in ntdll!LdrFindResource_U ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77dbf896 in ntdll!RtlQueryTimeZoneInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x0827293f in ?? ()
#3  0x00000000 in ?? ()

Thread 2 (Thread 6444.0x2ab4):
#0  0x77d4013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77d4013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x77d72f51 in ntdll!RtlWeaklyEnumerateEntryHashTable ()
    from C:\Windows\SysWOW64\ntdll.dll
#3  0x00000003 in ?? ()
#4  0x00ce1820 in ?? ()
#5  0x770d339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
    from C:\Windows\syswow64\kernel32.dll
#6  0x00000000 in ?? ()

Thread 1 (Thread 6444.0x2104):
#0  0x77d40542 in ntdll!RtlInitOutOfProcessMemoryStream ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77d40542 in ntdll!RtlInitOutOfProcessMemoryStream ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x768e75df in RPCRT4!NdrConformantVaryingArrayMarshall ()
    from C:\Windows\syswow64\rpcrt4.dll
#3  0x40020000 in ?? ()
#4  0x00d2eff8 in ?? ()
#5  0x768e7a7f in RPCRT4!NdrConformantVaryingArrayMarshall ()
    from C:\Windows\syswow64\rpcrt4.dll
#6  0x00d2eff8 in ?? ()
#7  0x768e7982 in RPCRT4!NdrConformantVaryingArrayMarshall ()
    from C:\Windows\syswow64\rpcrt4.dll
#8  0x00ce1140 in ?? ()
#9  0x768f0071 in RPCRT4!I_RpcEnableWmiTrace ()
    from C:\Windows\syswow64\rpcrt4.dll
#10 0x0088edb0 in ?? ()
#11 0x768e7391 in RPCRT4!NdrConformantVaryingArrayMarshall ()
    from C:\Windows\syswow64\rpcrt4.dll
#12 0x0088eddc in ?? ()
#13 0x768e804b in UuidCreateNil () from C:\Windows\syswow64\rpcrt4.dll
#14 0x768e801a in UuidCreateNil () from C:\Windows\syswow64\rpcrt4.dll
#15 0x75560d3e in SECHOST!LsaLookupGetDomainInfo ()
    from C:\Windows\SysWOW64\sechost.dll
#16 0x755545e8 in ?? () from C:\Windows\SysWOW64\sechost.dll
#17 0x75560966 in SECHOST!LsaLookupTranslateNames ()
    from C:\Windows\SysWOW64\sechost.dll
#18 0x75560a4c in SECHOST!LsaLookupTranslateSids ()
    from C:\Windows\SysWOW64\sechost.dll
#19 0x7556030b in SECHOST!LookupAccountNameLocalW ()
    from C:\Windows\SysWOW64\sechost.dll
#20 0x7556050c in SECHOST!LookupAccountSidLocalA ()
    from C:\Windows\SysWOW64\sechost.dll
#21 0x76821e1b in LookupAccountSidW () from C:\Windows\syswow64\advapi32.dll
#22 0x010572d7 in lookup_account_sid (lpSystemName=0x0, Sid=0xce1bc8,
     Name=0x88f7cf "humayun", cbName=0x88f7c8,
     DomainName=0x88f3c8 "GEOINFORMATIK", cbDomainName=0x88f3c4,
     peUse=0x88f8d0) at w32.c:495
#23 0x0105b343 in get_name_and_id (psd=0xce1b98,
     fname=0x88f970 "c:\\emacs-24.2.50\\etc\\GNU", id=0x88fbf4,
     nm=0x88fd14 "/emacs-24.2.50/etc/GNU", what=2) at w32.c:3437
#24 0x0105b43c in get_file_owner_and_group (psd=0xce1b98,
     fname=0x88f970 "c:\\emacs-24.2.50\\etc\\GNU", st=0x88fbe0) at 
w32.c:3467
#25 0x0105b91c in stat_worker (path=0x164a5c2 "\\emacs-24.2.50\\etc\\GNU",
     buf=0x88fbe0, follow_symlinks=1) at w32.c:3689
#26 0x0105bf49 in stat (path=0x39e9e50 "c:/emacs-24.2.50/etc/GNU",
     buf=0x88fbe0) at w32.c:3865
#27 0x01067a18 in Ffile_exists_p (filename=59080209) at fileio.c:2506
#28 0x010d48f1 in init_callproc () at callproc.c:1582
#29 0x0100289b in main (argc=1, argv=0xa32c18) at emacs.c:1435
Detaching from program: C:\emacs-24.2.50\bin\emacs.exe, Pid 6444

===================
After Welcome Screen
===================
Attaching to program `C:\emacs-24.2.50\bin\emacs.exe', process 6444
[New Thread 6444.0x2104]
[New Thread 6444.0x2ab4]
[New Thread 6444.0x1338]
[New Thread 6444.0x2cf0]
[New Thread 6444.0x2fe0]
[New Thread 6444.0x1708]
[New Thread 6444.0x2fbc]

Thread 7 (Thread 6444.0x2fbc):
#0  0x77d3000d in ntdll!LdrFindResource_U ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77dbf896 in ntdll!RtlQueryTimeZoneInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x0cdf293f in ?? ()
#3  0x00000000 in ?? ()

Thread 6 (Thread 6444.0x1708):
#0  0x77d41f26 in ntdll!LdrQueryProcessModuleInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77d41f26 in ntdll!LdrQueryProcessModuleInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x77d73352 in ntdll!RtlCreateTagHeap () from 
C:\Windows\SysWOW64\ntdll.dll
#3  0x00000144 in ?? ()
#4  0x738cfedc in ?? ()
#5  0x770d339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
    from C:\Windows\syswow64\kernel32.dll
#6  0x00d32ef8 in ?? ()
#7  0x77d59ef2 in ntdll!RtlpNtSetValueKey ()
    from C:\Windows\SysWOW64\ntdll.dll
#8  0x00d32ef8 in ?? ()
#9  0x77d59ec5 in ntdll!RtlpNtSetValueKey ()
    from C:\Windows\SysWOW64\ntdll.dll
#10 0x77d73e45 in ntdll!RtlSidIsHigherLevel ()
    from C:\Windows\SysWOW64\ntdll.dll
#11 0x00d32ef8 in ?? ()
#12 0x00000000 in ?? ()

Thread 5 (Thread 6444.0x2fe0):
#0  0x77d41f26 in ntdll!LdrQueryProcessModuleInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77d41f26 in ntdll!LdrQueryProcessModuleInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x77d73352 in ntdll!RtlCreateTagHeap () from 
C:\Windows\SysWOW64\ntdll.dll
#3  0x00000134 in ?? ()
#4  0x7178fedc in ?? ()
#5  0x770d339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
    from C:\Windows\syswow64\kernel32.dll
#6  0x00d32ef8 in ?? ()
#7  0x77d59ef2 in ntdll!RtlpNtSetValueKey ()
    from C:\Windows\SysWOW64\ntdll.dll
#8  0x00d32ef8 in ?? ()
#9  0x77d59ec5 in ntdll!RtlpNtSetValueKey ()
    from C:\Windows\SysWOW64\ntdll.dll
#10 0x77d73e45 in ntdll!RtlSidIsHigherLevel ()
    from C:\Windows\SysWOW64\ntdll.dll
#11 0x00d32ef8 in ?? ()
#12 0x00000000 in ?? ()

Thread 4 (Thread 6444.0x2cf0):
#0  0x77d41f26 in ntdll!LdrQueryProcessModuleInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77d41f26 in ntdll!LdrQueryProcessModuleInformation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x77d73352 in ntdll!RtlCreateTagHeap () from 
C:\Windows\SysWOW64\ntdll.dll
#3  0x0000017c in ?? ()
#4  0x70f4fedc in ?? ()
#5  0x770d339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
    from C:\Windows\syswow64\kernel32.dll
#6  0x00d33b88 in ?? ()
#7  0x77d59ef2 in ntdll!RtlpNtSetValueKey ()
    from C:\Windows\SysWOW64\ntdll.dll
#8  0x00d33b88 in ?? ()
#9  0x77d59ec5 in ntdll!RtlpNtSetValueKey ()
    from C:\Windows\SysWOW64\ntdll.dll
#10 0x77d73e45 in ntdll!RtlSidIsHigherLevel ()
    from C:\Windows\SysWOW64\ntdll.dll
#11 0x00d33b88 in ?? ()
#12 0x00000000 in ?? ()

Thread 3 (Thread 6444.0x1338):
#0  0x773778d7 in USER32!IsDialogMessage ()
    from C:\Windows\syswow64\user32.dll
#1  0x773778d7 in USER32!IsDialogMessage ()
    from C:\Windows\syswow64\user32.dll
#2  0x7737790d in USER32!GetCursorPos () from C:\Windows\syswow64\user32.dll
#3  0x730cfec0 in ?? ()
#4  0x011490bd in w32_msg_pump (msg_buf=0x730cff28) at w32fns.c:2263
#5  0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#6  0x770d339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
    from C:\Windows\syswow64\kernel32.dll
#7  0x00000000 in ?? ()

Thread 2 (Thread 6444.0x2ab4):
#0  0x77d4013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77d4013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x77d72f51 in ntdll!RtlWeaklyEnumerateEntryHashTable ()
    from C:\Windows\SysWOW64\ntdll.dll
#3  0x00000003 in ?? ()
#4  0x00ce1820 in ?? ()
#5  0x770d339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
    from C:\Windows\syswow64\kernel32.dll
#6  0x00000000 in ?? ()

Thread 1 (Thread 6444.0x2104):
#0  0x77d4013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
    from C:\Windows\SysWOW64\ntdll.dll
#1  0x77d4013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
    from C:\Windows\SysWOW64\ntdll.dll
#2  0x75510bdd in WaitForMultipleObjectsEx ()
    from C:\Windows\syswow64\KernelBase.dll
#3  0x00000003 in ?? ()
#4  0x0088f1d4 in ?? ()
#5  0x770d1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA ()
    from C:\Windows\syswow64\kernel32.dll
#6  0x0088f1d4 in ?? ()
#7  0x7738086a in USER32!MessageBoxA () from C:\Windows\syswow64\user32.dll
#8  0x00000003 in ?? ()
#9  0x7efde000 in ?? ()
#10 0x77380b69 in USER32!DdeNameService () from 
C:\Windows\syswow64\user32.dll
#11 0x00000050 in ?? ()
#12 0x0088f400 in ?? ()
#13 0x010551a1 in sys_select (nfds=1, rfds=0x88f6c0, wfds=0x0, efds=0x0,
     timeout=0x88f6b0, ignored=0x0) at w32proc.c:1270
#14 0x0104cd4e in wait_reading_process_output (time_limit=28, nsecs=0,
     read_kbd=-1, do_display=1, wait_for_cell=56346650, wait_proc=0x0,
     just_wait_proc=0) at process.c:4647
#15 0x010fbc2a in sit_for (timeout=112, reading=true, do_display=1)
     at dispnew.c:5977
#16 0x010095c4 in read_char (commandflag=1, nmaps=2, maps=0x88f960,
     prev_event=56346650, used_mouse_menu=0x88fa38, end_time=0x0)
     at keyboard.c:2707
#17 0x0101ccb2 in read_key_sequence (keybuf=0x88fbc0, bufsize=30,
     prompt=56346650, dont_downcase_last=0, can_return_switch_frame=1,
     fix_current_buffer=1) at keyboard.c:9312
#18 0x01005f89 in command_loop_1 () at keyboard.c:1487
#19 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>,
     handlers=56397234, hfun=0x100526a <cmd_error>) at eval.c:1308
#20 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#21 0x010320bb in internal_catch (tag=56387090,
     func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#22 0x0100567e in command_loop () at keyboard.c:1161
#23 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#24 0x01004f54 in Frecursive_edit () at keyboard.c:846
#25 0x01002b68 in main (argc=1, argv=0xa32c18) at emacs.c:1655
Detaching from program: C:\emacs-24.2.50\bin\emacs.exe, Pid 6444

-----------------------------------------------------------------------------------------------

PS: In case you're wondering how the gdb log's like when netlogon 
process is not running, see http://pastebin.com/DRuxk2ms

Thanks for actively following up on this.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> Date: Mon, 08 Oct 2012 16:34:18 +0200
> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> ========================
> Before Welcome Screen
> =======================

This part is clear: we are waiting for file security-related system
calls:

> #21 0x76821e1b in LookupAccountSidW () from C:\Windows\syswow64\advapi32.dll
> #22 0x010572d7 in lookup_account_sid (lpSystemName=0x0, Sid=0xce1bc8,
>      Name=0x88f7cf "humayun", cbName=0x88f7c8,
>      DomainName=0x88f3c8 "GEOINFORMATIK", cbDomainName=0x88f3c4,
>      peUse=0x88f8d0) at w32.c:495
> #23 0x0105b343 in get_name_and_id (psd=0xce1b98,
>      fname=0x88f970 "c:\\emacs-24.2.50\\etc\\GNU", id=0x88fbf4,
>      nm=0x88fd14 "/emacs-24.2.50/etc/GNU", what=2) at w32.c:3437
> #24 0x0105b43c in get_file_owner_and_group (psd=0xce1b98,
>      fname=0x88f970 "c:\\emacs-24.2.50\\etc\\GNU", st=0x88fbe0) at 
> w32.c:3467
> #25 0x0105b91c in stat_worker (path=0x164a5c2 "\\emacs-24.2.50\\etc\\GNU",
>      buf=0x88fbe0, follow_symlinks=1) at w32.c:3689
> #26 0x0105bf49 in stat (path=0x39e9e50 "c:/emacs-24.2.50/etc/GNU",
>      buf=0x88fbe0) at w32.c:3865
> #27 0x01067a18 in Ffile_exists_p (filename=59080209) at fileio.c:2506
> #28 0x010d48f1 in init_callproc () at callproc.c:1582

As you see, these calls are originated from a function that needs to
establish whether a certain file exists.  In a Windows domain, these
calls go to the domain controller, and are evidently very slow when
the Netlogon service is up and running.  I think I can find a solution
for this.

> ===================
> After Welcome Screen
> ===================
> Attaching to program `C:\emacs-24.2.50\bin\emacs.exe', process 6444
> [New Thread 6444.0x2104]
> [New Thread 6444.0x2ab4]
> [New Thread 6444.0x1338]
> [New Thread 6444.0x2cf0]
> [New Thread 6444.0x2fe0]
> [New Thread 6444.0x1708]
> [New Thread 6444.0x2fbc]

I don't understand why we have 7 threads, while there are only 3 in
the previous case.  Can you please run Emacs under GDB to begin with,
and show where these threads are started.  Like this:

   cd \path\to\emacs.exe
   gdb ./emacs.exe
   (gdb) break CreateThread

(GDB will ask whether to make this breakpoint pending on future shared
library load; answer YES.)

   (gdb) commands
   backtrace
   continue
   end
   (gdb) run -Q

Now, whenever another thread is created, GDB will stop Emacs and print
the backtrace, then Emacs will continue.  Please show the results
here.

The main thread is just sitting in sys_select, waiting for input:

> #13 0x010551a1 in sys_select (nfds=1, rfds=0x88f6c0, wfds=0x0, efds=0x0,
>      timeout=0x88f6b0, ignored=0x0) at w32proc.c:1270
> #14 0x0104cd4e in wait_reading_process_output (time_limit=28, nsecs=0,
>      read_kbd=-1, do_display=1, wait_for_cell=56346650, wait_proc=0x0,
>      just_wait_proc=0) at process.c:4647
> #15 0x010fbc2a in sit_for (timeout=112, reading=true, do_display=1)
>      at dispnew.c:5977
> #16 0x010095c4 in read_char (commandflag=1, nmaps=2, maps=0x88f960,
>      prev_event=56346650, used_mouse_menu=0x88fa38, end_time=0x0)
>      at keyboard.c:2707
> #17 0x0101ccb2 in read_key_sequence (keybuf=0x88fbc0, bufsize=30,
>      prompt=56346650, dont_downcase_last=0, can_return_switch_frame=1,
>      fix_current_buffer=1) at keyboard.c:9312
> #18 0x01005f89 in command_loop_1 () at keyboard.c:1487

This means Emacs is idle and waits for the user to type something, or
for some Windows event to come in.  This is normal.

I see that I misinterpreted your original report about the startup
time line.  I now understand that after the welcome screen Emacs is
responsive, and the slowdown is before the welcome screen.

So please repeat what you did, but do it once before the GUI shows up,
and then again between the time the GUI shows up and the time Emacs
shows its welcome screen.  (If you know to which of these two time
instances belongs the first backtrace you show above, you need only to
produce the backtrace for the other time instance.)

Thanks.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> Date: Mon, 08 Oct 2012 17:47:15 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12587@debbugs.gnu.org
> 
> This part is clear: we are waiting for file security-related system
> calls:
> 
> > #21 0x76821e1b in LookupAccountSidW () from C:\Windows\syswow64\advapi32.dll
> > #22 0x010572d7 in lookup_account_sid (lpSystemName=0x0, Sid=0xce1bc8,
> >      Name=0x88f7cf "humayun", cbName=0x88f7c8,
> >      DomainName=0x88f3c8 "GEOINFORMATIK", cbDomainName=0x88f3c4,
> >      peUse=0x88f8d0) at w32.c:495
> > #23 0x0105b343 in get_name_and_id (psd=0xce1b98,
> >      fname=0x88f970 "c:\\emacs-24.2.50\\etc\\GNU", id=0x88fbf4,
> >      nm=0x88fd14 "/emacs-24.2.50/etc/GNU", what=2) at w32.c:3437
> > #24 0x0105b43c in get_file_owner_and_group (psd=0xce1b98,
> >      fname=0x88f970 "c:\\emacs-24.2.50\\etc\\GNU", st=0x88fbe0) at 
> > w32.c:3467
> > #25 0x0105b91c in stat_worker (path=0x164a5c2 "\\emacs-24.2.50\\etc\\GNU",
> >      buf=0x88fbe0, follow_symlinks=1) at w32.c:3689
> > #26 0x0105bf49 in stat (path=0x39e9e50 "c:/emacs-24.2.50/etc/GNU",
> >      buf=0x88fbe0) at w32.c:3865
> > #27 0x01067a18 in Ffile_exists_p (filename=59080209) at fileio.c:2506
> > #28 0x010d48f1 in init_callproc () at callproc.c:1582
> 
> As you see, these calls are originated from a function that needs to
> establish whether a certain file exists.  In a Windows domain, these
> calls go to the domain controller, and are evidently very slow when
> the Netlogon service is up and running.  I think I can find a solution
> for this.

I committed a change in trunk revision 110520 which should make this
part faster, as these functions now avoid calling 'stat' as much as
possible.  When the binaries of the next development snapshot appear
on http://alpha.gnu.org/gnu/emacs/windows/, or if you can build Emacs
yourself, please try that and see if things are better now when the
Netlogon service is running.

> I see that I misinterpreted your original report about the startup
> time line.  I now understand that after the welcome screen Emacs is
> responsive, and the slowdown is before the welcome screen.
> 
> So please repeat what you did, but do it once before the GUI shows up,
> and then again between the time the GUI shows up and the time Emacs
> shows its welcome screen.  (If you know to which of these two time
> instances belongs the first backtrace you show above, you need only to
> produce the backtrace for the other time instance.)

I'd still like to see this information, to make sure there isn't any
other place that slows down the startup.

Thanks.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Mohammed Imaduddin Humayun]

On 10/12/2012 5:27 PM, Eli Zaretskii wrote:
> I committed a change in trunk revision 110520 which should make this
> part faster, as these functions now avoid calling 'stat' as much as
> possible.  When the binaries of the next development snapshot appear
> on http://alpha.gnu.org/gnu/emacs/windows/, or if you can build Emacs
> yourself, please try that and see if things are better now when the
> Netlogon service is running.
Thanks. I will try this once the next snapshot binaries are released or 
earlier if I manage to build it myself.
>> I see that I misinterpreted your original report about the startup
>> time line.  I now understand that after the welcome screen Emacs is
>> responsive, and the slowdown is before the welcome screen.
Just so we're on the same page this is roughly the timeline:
(start emacs)----------------(GUI 
appears)----------------------------------------------------(welcome screen)
    0s ------------------------------- ~2 min 
--------------------------------------------------------------- ~7 min
>> So please repeat what you did, but do it once before the GUI shows up,
>> and then again between the time the GUI shows up and the time Emacs
>> shows its welcome screen.  (If you know to which of these two time
>> instances belongs the first backtrace you show above, you need only to
>> produce the backtrace for the other time instance.)
I'm not clear on this. Wouldn't the backtrace be the same if I just 
produce it for the latter time instance (welcome screen) given that this 
happens only after the GUI shows up?

> I'd still like to see this information, to make sure there isn't any
> other place that slows down the startup.
Sorry I couldn't find time to do this sooner, but the following steps 
didn't give the backtrace as expected  ... :

cd \path\to\emacs.exe
gdb ./emacs.exe
(gdb) break CreateThread
(Answer 'y' when GDB asks whether to make this breakpoint pending on future shared
library load)
(gdb) commands
backtrace
continue
end
(gdb) run -Q


... and below is the log, but no backtrace was shown:
------------------------------------------------------
Function "CreateThread" not defined.
Make breakpoint pending on future shared library load? (y or [n])
Breakpoint 1 (CreateThread) pending.
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
Starting program: C:\emacs-24.2.50\bin\emacs.exe
[New Thread 9940.0x2db0]
[New Thread 9940.0x2bbc]
[New Thread 9940.0x2c0c]
[New Thread 9940.0x2ed0]
[New Thread 9940.0x2840]
[New Thread 9940.0xe8c]
[New Thread 9940.0x7e8]
[New Thread 9940.0xe3c]
[New Thread 9940.0x1284]
[New Thread 9940.0x11d4]
[Inferior 1 (process 9940) exited normally]
-------------------------------------------------------------

What do I need to rectify here?

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> Date: Sun, 14 Oct 2012 15:03:33 +0200
> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> Just so we're on the same page this is roughly the timeline:
> (start emacs)----------------(GUI 
> appears)----------------------------------------------------(welcome screen)
>     0s ------------------------------- ~2 min 
> --------------------------------------------------------------- ~7 min

Yes, I understand that.

> >> So please repeat what you did, but do it once before the GUI shows up,
> >> and then again between the time the GUI shows up and the time Emacs
> >> shows its welcome screen.  (If you know to which of these two time
> >> instances belongs the first backtrace you show above, you need only to
> >> produce the backtrace for the other time instance.)
> I'm not clear on this. Wouldn't the backtrace be the same if I just 
> produce it for the latter time instance (welcome screen) given that this 
> happens only after the GUI shows up?

No, it isn't necessarily so.  Emacs does a series of initializations
during these phases, and looks for quite a long list of files, so you
might as well see an entirely different backtrace.  I'd like to make
sure that LookupAccountSidW, called from 'stat', is the only function
that slows down the startup.

> > I'd still like to see this information, to make sure there isn't any
> > other place that slows down the startup.
> Sorry I couldn't find time to do this sooner, but the following steps 
> didn't give the backtrace as expected  ... :
> 
> cd \path\to\emacs.exe
> gdb ./emacs.exe
> (gdb) break CreateThread
> (Answer 'y' when GDB asks whether to make this breakpoint pending on future shared
> library load)
> (gdb) commands
> backtrace
> continue
> end
> (gdb) run -Q
> 
> 
> ... and below is the log, but no backtrace was shown:
> ------------------------------------------------------
> Function "CreateThread" not defined.
> Make breakpoint pending on future shared library load? (y or [n])
> Breakpoint 1 (CreateThread) pending.
> Type commands for breakpoint(s) 1, one per line.
> End with a line saying just "end".
> Starting program: C:\emacs-24.2.50\bin\emacs.exe
> [New Thread 9940.0x2db0]
> [New Thread 9940.0x2bbc]
> [New Thread 9940.0x2c0c]
> [New Thread 9940.0x2ed0]
> [New Thread 9940.0x2840]
> [New Thread 9940.0xe8c]
> [New Thread 9940.0x7e8]
> [New Thread 9940.0xe3c]
> [New Thread 9940.0x1284]
> [New Thread 9940.0x11d4]
> [Inferior 1 (process 9940) exited normally]
> -------------------------------------------------------------
> 
> What do I need to rectify here?

No, that's fine.  I think the issue with CreateThread is a red herring
anyway, sorry.  The only additional information I'd like to see is the
backtrace during the time between the instance the GUI shows up and
the welcome screen.

Thanks.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Mohammed Imaduddin Humayun]

On 10/14/2012 4:53 PM, Eli Zaretskii wrote:
> No, that's fine. I think the issue with CreateThread is a red herring 
> anyway, sorry. The only additional information I'd like to see is the 
> backtrace during the time between the instance the GUI shows up and 
> the welcome screen. Thanks. 

Here it is:
--------------------------------------------------------------
Thread 7 (Thread 12476.0x27f8):
#0 0x770e000d in ntdll!LdrFindResource_U ()
from C:\Windows\SysWOW64\ntdll.dll
#1 0x7716f896 in ntdll!RtlQueryTimeZoneInformation ()
from C:\Windows\SysWOW64\ntdll.dll
#2 0x236775da in ?? ()
#3 0x00000000 in ?? ()

Thread 6 (Thread 12476.0xb4c):
#0 0x74ee78d7 in USER32!IsDialogMessage ()
from C:\Windows\syswow64\user32.dll
#1 0x74ee78d7 in USER32!IsDialogMessage ()
from C:\Windows\syswow64\user32.dll
#2 0x74ee790d in USER32!GetCursorPos () from C:\Windows\syswow64\user32.dll
#3 0x72bffec0 in ?? ()
#4 0x011490bd in w32_msg_pump (msg_buf=0x72bfff28) at w32fns.c:2263
#5 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#6 0x74c033aa in KERNEL32!BaseCleanupAppcompatCacheSupport ()
from C:\Windows\syswow64\kernel32.dll
#7 0x72bfffd4 in ?? ()
#8 0x77109ef2 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#9 0x00000000 in ?? ()

Thread 5 (Thread 12476.0x2e70):
#0 0x770f1f26 in ntdll!LdrQueryProcessModuleInformation ()
from C:\Windows\SysWOW64\ntdll.dll
#1 0x770f1f26 in ntdll!LdrQueryProcessModuleInformation ()
from C:\Windows\SysWOW64\ntdll.dll
#2 0x77123352 in ntdll!RtlCreateTagHeap () from 
C:\Windows\SysWOW64\ntdll.dll
#3 0x0000012c in ?? ()
#4 0x7183fedc in ?? ()
#5 0x74c033aa in KERNEL32!BaseCleanupAppcompatCacheSupport ()
from C:\Windows\syswow64\kernel32.dll
#6 0x7183ffd4 in ?? ()
#7 0x77109ef2 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#8 0x00cb2ef8 in ?? ()
#9 0x77109ec5 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#10 0x77123e45 in ntdll!RtlSidIsHigherLevel ()
from C:\Windows\SysWOW64\ntdll.dll
#11 0x00cb2ef8 in ?? ()
#12 0x00000000 in ?? ()

Thread 4 (Thread 12476.0x30a4):
#0 0x770f1f26 in ntdll!LdrQueryProcessModuleInformation ()
from C:\Windows\SysWOW64\ntdll.dll
#1 0x770f1f26 in ntdll!LdrQueryProcessModuleInformation ()
from C:\Windows\SysWOW64\ntdll.dll
#2 0x77123352 in ntdll!RtlCreateTagHeap () from 
C:\Windows\SysWOW64\ntdll.dll
#3 0x0000013c in ?? ()
#4 0x7203fedc in ?? ()
#5 0x74c033aa in KERNEL32!BaseCleanupAppcompatCacheSupport ()
from C:\Windows\syswow64\kernel32.dll
#6 0x7203ffd4 in ?? ()
#7 0x77109ef2 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#8 0x00cb2ef8 in ?? ()
#9 0x77109ec5 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#10 0x77123e45 in ntdll!RtlSidIsHigherLevel ()
from C:\Windows\SysWOW64\ntdll.dll
#11 0x00cb2ef8 in ?? ()
#12 0x00000000 in ?? ()

Thread 3 (Thread 12476.0x1a74):
#0 0x770f1f26 in ntdll!LdrQueryProcessModuleInformation ()
from C:\Windows\SysWOW64\ntdll.dll
#1 0x770f1f26 in ntdll!LdrQueryProcessModuleInformation ()
from C:\Windows\SysWOW64\ntdll.dll
#2 0x77123352 in ntdll!RtlCreateTagHeap () from 
C:\Windows\SysWOW64\ntdll.dll
#3 0x0000017c in ?? ()
#4 0x7103fedc in ?? ()
#5 0x74c033aa in KERNEL32!BaseCleanupAppcompatCacheSupport ()
from C:\Windows\syswow64\kernel32.dll
#6 0x7103ffd4 in ?? ()
#7 0x77109ef2 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#8 0x00cb3b88 in ?? ()
#9 0x77109ec5 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#10 0x77123e45 in ntdll!RtlSidIsHigherLevel ()
from C:\Windows\SysWOW64\ntdll.dll
#11 0x00cb3b88 in ?? ()
#12 0x00000000 in ?? ()

Thread 2 (Thread 12476.0x2d54):
#0 0x770f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\SysWOW64\ntdll.dll
#1 0x770f013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\SysWOW64\ntdll.dll
#2 0x77122f51 in ntdll!RtlWeaklyEnumerateEntryHashTable ()
from C:\Windows\SysWOW64\ntdll.dll
#3 0x00000003 in ?? ()
#4 0x00c61820 in ?? ()
#5 0x74c033aa in KERNEL32!BaseCleanupAppcompatCacheSupport ()
from C:\Windows\syswow64\kernel32.dll
#6 0x7083ffd4 in ?? ()
#7 0x77109ef2 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#8 0x00c617f0 in ?? ()
#9 0x77109ec5 in ntdll!RtlpNtSetValueKey ()
from C:\Windows\SysWOW64\ntdll.dll
#10 0x77122e25 in ntdll!RtlWeaklyEnumerateEntryHashTable ()
from C:\Windows\SysWOW64\ntdll.dll
#11 0x00c617f0 in ?? ()
#12 0x00000000 in ?? ()

Thread 1 (Thread 12476.0x1db0):
#0 0x770f0542 in ntdll!RtlInitOutOfProcessMemoryStream ()
from C:\Windows\SysWOW64\ntdll.dll
#1 0x770f0542 in ntdll!RtlInitOutOfProcessMemoryStream ()
from C:\Windows\SysWOW64\ntdll.dll
#2 0x748775df in RPCRT4!NdrConformantVaryingArrayMarshall ()
from C:\Windows\syswow64\rpcrt4.dll
#3 0x40020000 in ?? ()
#4 0x00caeff8 in ?? ()
#5 0x74877a7f in RPCRT4!NdrConformantVaryingArrayMarshall ()
from C:\Windows\syswow64\rpcrt4.dll
#6 0x00caeff8 in ?? ()
#7 0x74877982 in RPCRT4!NdrConformantVaryingArrayMarshall ()
from C:\Windows\syswow64\rpcrt4.dll
#8 0x00cc7e98 in ?? ()
#9 0x74880071 in RPCRT4!I_RpcEnableWmiTrace ()
from C:\Windows\syswow64\rpcrt4.dll
#10 0x0088d890 in ?? ()
#11 0x74877391 in RPCRT4!NdrConformantVaryingArrayMarshall ()
from C:\Windows\syswow64\rpcrt4.dll
#12 0x0088d8bc in ?? ()
#13 0x7487804b in UuidCreateNil () from C:\Windows\syswow64\rpcrt4.dll
#14 0x7487801a in UuidCreateNil () from C:\Windows\syswow64\rpcrt4.dll
#15 0x75540d3e in SECHOST!LsaLookupGetDomainInfo ()
from C:\Windows\SysWOW64\sechost.dll
#16 0x755345e8 in ?? () from C:\Windows\SysWOW64\sechost.dll
#17 0x75540966 in SECHOST!LsaLookupTranslateNames ()
from C:\Windows\SysWOW64\sechost.dll
#18 0x75540a4c in SECHOST!LsaLookupTranslateSids ()
from C:\Windows\SysWOW64\sechost.dll
#19 0x7554030b in SECHOST!LookupAccountNameLocalW ()
from C:\Windows\SysWOW64\sechost.dll
#20 0x7554050c in SECHOST!LookupAccountSidLocalA ()
from C:\Windows\SysWOW64\sechost.dll
#21 0x76771e1b in LookupAccountSidW () from C:\Windows\syswow64\advapi32.dll
#22 0x010572d7 in lookup_account_sid (lpSystemName=0x0, Sid=0xcba790,
Name=0x88e2af "wéÜ‚t \002", cbName=0x88e2a8,
DomainName=0x88dea8 "<Þ\210", cbDomainName=0x88dea4, peUse=0x88e3b0)
at w32.c:495
#23 0x0105b343 in get_name_and_id (psd=0xcba760,
fname=0x88e450 "c:\\emacs-24.2.50\\info\\", id=0x88e6d4, nm=0x88e7f4 "",
what=2) at w32.c:3437
#24 0x0105b43c in get_file_owner_and_group (psd=0xcba760,
fname=0x88e450 "c:\\emacs-24.2.50\\info\\", st=0x88e6c0) at w32.c:3467
#25 0x0105b91c in stat_worker (path=0x164a5c2 "\\emacs-24.2.50\\info\\",
buf=0x88e6c0, follow_symlinks=1) at w32.c:3689
#26 0x0105bf49 in stat (path=0x367e1bc "c:/emacs-24.2.50/info/", 
buf=0x88e6c0)
at w32.c:3865
#27 0x01067a18 in Ffile_exists_p (filename=60362113) at fileio.c:2506
#28 0x01034973 in eval_sub (form=20511686) at eval.c:2157
#29 0x01030734 in Fcond (args=20511670) at eval.c:343
#30 0x0103453b in eval_sub (form=20511662) at eval.c:2105
#31 0x0103087a in Fprogn (args=20511654) at eval.c:369
#32 0x01031829 in FletX (args=20511486) at eval.c:853
#33 0x0103453b in eval_sub (form=20511478) at eval.c:2105
#34 0x0103087a in Fprogn (args=20511470) at eval.c:369
#35 0x010306fe in Fif (args=20511438) at eval.c:320
#36 0x0103453b in eval_sub (form=20511430) at eval.c:2105
#37 0x0103087a in Fprogn (args=20511422) at eval.c:369
#38 0x01031829 in FletX (args=20510430) at eval.c:853
#39 0x0103453b in eval_sub (form=20510422) at eval.c:2105
#40 0x010340a8 in Feval (form=20510422, lexical=56346650) at eval.c:2022
#41 0x0103670a in Ffuncall (nargs=2, args=0x88f0cc) at eval.c:2799
#42 0x010e0e77 in exec_byte_code (bytestr=20157409, vector=20157461,
maxdepth=20, args_template=56346650, nargs=0, args=0x0) at bytecode.c:899
#43 0x01037624 in funcall_lambda (fun=20157381, nargs=1, 
arg_vector=0x35bc81a)
at eval.c:3028
#44 0x01036abd in Ffuncall (nargs=2, args=0x88f3c8) at eval.c:2845
#45 0x01035e61 in call1 (fn=58045562, arg1=58471714) at eval.c:2590
#46 0x0107bf8c in mapcar1 (leni=16, vals=0x0, fn=58045562, seq=58091126)
at fns.c:2318
#47 0x0107c477 in Fmapc (function=58045562, sequence=58091126) at fns.c:2407
#48 0x0103670a in Ffuncall (nargs=3, args=0x88f524) at eval.c:2799
#49 0x010e0e77 in exec_byte_code (bytestr=20428473, vector=20429309,
maxdepth=72, args_template=0, nargs=0, args=0x88f85c) at bytecode.c:899
#50 0x010371c9 in funcall_lambda (fun=20428445, nargs=0, arg_vector=0x0)
at eval.c:2962
#51 0x01036abd in Ffuncall (nargs=1, args=0x88f858) at eval.c:2845
#52 0x010e0e77 in exec_byte_code (bytestr=20426345, vector=20426573,
maxdepth=32, args_template=0, nargs=0, args=0x88fac0) at bytecode.c:899
#53 0x010371c9 in funcall_lambda (fun=20426317, nargs=0, arg_vector=0x0)
at eval.c:2962
#54 0x01036dfe in apply_lambda (fun=20426317, args=56346650) at eval.c:2905
#55 0x01034dd4 in eval_sub (form=58030934) at eval.c:2202
#56 0x010340a8 in Feval (form=58030934, lexical=56346650) at eval.c:2022
#57 0x010056f7 in top_level_2 () at keyboard.c:1191
#58 0x0103269f in internal_condition_case (bfun=0x10056da <top_level_2>,
handlers=56397234, hfun=0x100526a <cmd_error>) at eval.c:1308
#59 0x0100572b in top_level_1 (ignore=56346650) at keyboard.c:1199
#60 0x010320bb in internal_catch (tag=56387090, func=0x10056f9 
<top_level_1>,
arg=56346650) at eval.c:1069
#61 0x0100565f in command_loop () at keyboard.c:1154
#62 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#63 0x01004f54 in Frecursive_edit () at keyboard.c:846
#64 0x01002b68 in main (argc=1, argv=0xc52c18) at emacs.c:1655
--------------------------------

Please let me know if you need additional debug info. Thanks.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> Date: Wed, 17 Oct 2012 10:47:44 +0200
> From: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>
> CC: Eli Zaretskii <eliz@gnu.org>
> 
> On 10/14/2012 4:53 PM, Eli Zaretskii wrote:
> > No, that's fine. I think the issue with CreateThread is a red herring 
> > anyway, sorry. The only additional information I'd like to see is the 
> > backtrace during the time between the instance the GUI shows up and 
> > the welcome screen. Thanks. 
> 
> Here it is:
> [...]
> Thread 1 (Thread 12476.0x1db0):
> #0 0x770f0542 in ntdll!RtlInitOutOfProcessMemoryStream ()
> from C:\Windows\SysWOW64\ntdll.dll
> #1 0x770f0542 in ntdll!RtlInitOutOfProcessMemoryStream ()
> from C:\Windows\SysWOW64\ntdll.dll
> #2 0x748775df in RPCRT4!NdrConformantVaryingArrayMarshall ()
> from C:\Windows\syswow64\rpcrt4.dll
> #3 0x40020000 in ?? ()
> #4 0x00caeff8 in ?? ()
> #5 0x74877a7f in RPCRT4!NdrConformantVaryingArrayMarshall ()
> from C:\Windows\syswow64\rpcrt4.dll
> #6 0x00caeff8 in ?? ()
> #7 0x74877982 in RPCRT4!NdrConformantVaryingArrayMarshall ()
> from C:\Windows\syswow64\rpcrt4.dll
> #8 0x00cc7e98 in ?? ()
> #9 0x74880071 in RPCRT4!I_RpcEnableWmiTrace ()
> from C:\Windows\syswow64\rpcrt4.dll
> #10 0x0088d890 in ?? ()
> #11 0x74877391 in RPCRT4!NdrConformantVaryingArrayMarshall ()
> from C:\Windows\syswow64\rpcrt4.dll
> #12 0x0088d8bc in ?? ()
> #13 0x7487804b in UuidCreateNil () from C:\Windows\syswow64\rpcrt4.dll
> #14 0x7487801a in UuidCreateNil () from C:\Windows\syswow64\rpcrt4.dll
> #15 0x75540d3e in SECHOST!LsaLookupGetDomainInfo ()
> from C:\Windows\SysWOW64\sechost.dll
> #16 0x755345e8 in ?? () from C:\Windows\SysWOW64\sechost.dll
> #17 0x75540966 in SECHOST!LsaLookupTranslateNames ()
> from C:\Windows\SysWOW64\sechost.dll
> #18 0x75540a4c in SECHOST!LsaLookupTranslateSids ()
> from C:\Windows\SysWOW64\sechost.dll
> #19 0x7554030b in SECHOST!LookupAccountNameLocalW ()
> from C:\Windows\SysWOW64\sechost.dll
> #20 0x7554050c in SECHOST!LookupAccountSidLocalA ()
> from C:\Windows\SysWOW64\sechost.dll
> #21 0x76771e1b in LookupAccountSidW () from C:\Windows\syswow64\advapi32.dll
> #22 0x010572d7 in lookup_account_sid (lpSystemName=0x0, Sid=0xcba790,
> Name=0x88e2af "wéÜ‚t \002", cbName=0x88e2a8,
> DomainName=0x88dea8 "<Þ\210", cbDomainName=0x88dea4, peUse=0x88e3b0)
> at w32.c:495
> #23 0x0105b343 in get_name_and_id (psd=0xcba760,
> fname=0x88e450 "c:\\emacs-24.2.50\\info\\", id=0x88e6d4, nm=0x88e7f4 "",
> what=2) at w32.c:3437
> #24 0x0105b43c in get_file_owner_and_group (psd=0xcba760,
> fname=0x88e450 "c:\\emacs-24.2.50\\info\\", st=0x88e6c0) at w32.c:3467
> #25 0x0105b91c in stat_worker (path=0x164a5c2 "\\emacs-24.2.50\\info\\",
> buf=0x88e6c0, follow_symlinks=1) at w32.c:3689
> #26 0x0105bf49 in stat (path=0x367e1bc "c:/emacs-24.2.50/info/", 
> buf=0x88e6c0) at w32.c:3865
> #27 0x01067a18 in Ffile_exists_p (filename=60362113) at fileio.c:2506

Thanks, this is the same issue as your first backtrace.

So now I'm sure that the calls to 'stat' to find out whether files
exist are the culprit, and I hope that due to the changes I made in
the development sources, which avoid calling 'stat' for this purpose,
the next release of Emacs will be free of this problem.

If you can afford it, please try the next development snapshot that
will appear here:

  http://alpha.gnu.org/gnu/emacs/windows/

I will wait for you or someone else to try a recent snapshot and
report the results, before I close the bug.

Thanks again for your efforts in this matter.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If you can afford it, please try the next development snapshot that
> will appear here:
>
>   http://alpha.gnu.org/gnu/emacs/windows/
>
> I will wait for you or someone else to try a recent snapshot and
> report the results, before I close the bug.

This bug can perhaps be closed now?  It's been a year or so.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>,  12587@debbugs.gnu.org
> Date: Tue, 04 Feb 2014 18:11:30 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you can afford it, please try the next development snapshot that
> > will appear here:
> >
> >   http://alpha.gnu.org/gnu/emacs/windows/
> >
> > I will wait for you or someone else to try a recent snapshot and
> > report the results, before I close the bug.
> 
> This bug can perhaps be closed now?  It's been a year or so.

I think so.

bug#12587: 24.2; Delayed startup, unresponsive Emacs in MS Windows when netlogon services is running in a domain

[Mohammed Imaduddin Humayun]

On 2/5/2014 4:50 AM, Eli Zaretskii wrote:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Mohammed Imaduddin Humayun <m_huma01@uni-muenster.de>,  12587@debbugs.gnu.org
>> Date: Tue, 04 Feb 2014 18:11:30 -0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> If you can afford it, please try the next development snapshot that
>>> will appear here:
>>>
>>>    http://alpha.gnu.org/gnu/emacs/windows/
>>>
>>> I will wait for you or someone else to try a recent snapshot and
>>> report the results, before I close the bug.
>> This bug can perhaps be closed now?  It's been a year or so.
> I think so.
Sorry for not following up. There seems to be no problem with the latest 
stable release. I agree that this bug can be closed.