AW: Subversion 1.6.18 released
Hi Stefan, Thanks for the new release! From the list of changes for 1.6.18 I learned that the server side performance of log -g was improved (r1152282). This sounds particularly interesting for our setup. Does a similar fix exist in 1.7.4, too? Regards, Thomas This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
AW: Strange behavior on directory delete/commit
You could also delete the directory directly in the repository using svn delete url -m message. This way you would avoid the problem of committing partial changes of your working copy. Regards, Thomas -Ursprüngliche Nachricht- Von: Dominik Psenner [mailto:dpsen...@gmail.com] Gesendet: Dienstag, 2. August 2011 08:41 An: users@subversion.apache.org Betreff: Strange behavior on directory delete/commit [...] To get things done, one would have to backup foobar somewhere, revert foobar, do the commit without PATH arguments and copy foobar over to the WC. *eek* Let me know what you think about this! Greetings, D. This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschäftsführer: Stephen Callaghan, Martin Timmann. .
AW: 1.7 compatibility issue
I can confirm that listing the repository works with --config-option servers:global:http-library=neon. As reported by Ivan he fixed this issue in r1151177. Thanks! Regards, Thomas Von: Mark Phippard [mailto:markp...@gmail.com] Gesendet: Dienstag, 26. Juli 2011 18:17 An: Becker, Thomas Cc: users@subversion.apache.org Betreff: Re: 1.7 compatibility issue On Tue, Jul 26, 2011 at 11:44 AM, Becker, Thomas thomas.bec...@torex.com wrote: Sorry for the confusion: stands for svn/repo_name, stands for server_host. The URL looks like https://server_host:8443/svn/repo_name. So you are saying you cannot even do svn ls against a repository? The automated test suite would exercise that. It could be some incompatibility between the client binaries and the way VisualSVN configures authentication or something like that. The binaries are probably using ra_serf to talk to the repository, which is new in 1.7. You can try configuring your client to use Neon as the default. Edit %APPDATA%\Subversion\config and add: http-library = neon At the bottom. -- Thanks Mark Phippard http://markphip.blogspot.com/ This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
1.7 compatibility issue
Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn _binaries.windows ). With the alpha and beta clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' svn: E175009: XML parsing failed: (400 Bad Request) The Visual SVN event log shows the message Hostname :8443 provided via SNI and hostname provided via HTTP are different. There seems to be a missing port number which reminded me of a discussion in thread 1.7.0-alpha1 feedback (http://svn.haxx.se/users/archive-2011-06/0263.shtml). Maybe this is related. Versions svn-1.7.0-dev-win32-r1136035.zip and earlier work, though. Regards, Thomas This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
AW: 1.7 compatibility issue
Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas -Ursprüngliche Nachricht- Von: Ivan Zhakov [mailto:i...@visualsvn.com] Gesendet: Dienstag, 26. Juli 2011 11:26 An: Becker, Thomas Cc: users@subversion.apache.org Betreff: Re: 1.7 compatibility issue On Tue, Jul 26, 2011 at 12:34, Becker, Thomas thomas.bec...@torex.com wrote: Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows ). With the alpha and beta clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' The URL for VisualSVN Server repositories should be like https:/xxx:8443/svn/. Please make sure that you are using correct URL to repository. -- Ivan Zhakov This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschäftsführer: Stephen Callaghan, Martin Timmann. .
strange merge conflict wrt. keywords
Hi, We encountered a strange merge conflict: A branch was created from trunk, nothing was ever committed to this branch and this branch was never the source of a merge. After some time, when merging from trunk to the freshly checked-out branch we got a text conflict for a particular file. It turned out that the trunk version of this file had substituted keywords in the repository when the branch was created. With the next commit on trunk this changed back to the un-expanded forms. The change of the revision where the substituted keywords appeared in the repository was a move of three files in order to change an upper case letter to lower case in the file names. However, the substituted keywords appeared only in one of the files. The svn:keywords property was Id Date Revision Author URL for all three files in all revisions. My assumption is that when doing the merge from trunk to branch the keyword line is subject to an incoming change (because they changed back to the generic form on trunk) as well as to local substitution which leads to the observed conflict. My questions now are: - Is this the expected behaviour or should incoming changes on keywords be ignored? - How could the substituted keyword get into the repository? For the revision where the substituted keywords appear in the repository we used Windows clients and server (Visual SVN) in whatever version was recent in January 2011. The merge conflict can be observed with Linux and Windows clients in various 1.6 versions. Regards, Thomas This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
AW: 1.7 compatibility issue
Sorry for the confusion: stands for svn/repo_name, stands for server_host. The URL looks like https://server_host:8443/svn/repo_name. Regards, Thomas Von: Mark Phippard [mailto:markp...@gmail.com] Gesendet: Dienstag, 26. Juli 2011 16:54 An: Becker, Thomas Cc: users@subversion.apache.org Betreff: Re: 1.7 compatibility issue On Tue, Jul 26, 2011 at 4:34 AM, Becker, Thomas thomas.bec...@torex.com wrote: Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn _binaries.windows ). With the alpha and beta clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' svn: E175009: XML parsing failed: (400 Bad Request) Does the SVN ls command even support this? I was not aware that it did. When I try it from OSX using 1.6 and 1.7 this is what I get: 1.6: $ /usr/bin/svn ls http://cu171.cloud.sp.collab.net/svn/ svn: Repository moved temporarily to 'http://cu171.cloud.sp.collab.net/svn/'; please relocate 1.7: $ svn ls http://cu171.cloud.sp.collab.net/svn/ svn: E175011: Unable to connect to a repository at URL 'http://cu171.cloud.sp.collab.net/svn' subversion/libsvn_ra_neon/util.c:607: (apr_err=175011) svn: E175011: Repository moved temporarily to 'http://cu171.cloud.sp.collab.net/svn'; please relocate In my case the server is running 1.7 as well. I can browse the list of repositories using my web browser. FWIW, that is all I thought this feature was supposed to support. -- Thanks Mark Phippard http://markphip.blogspot.com/ This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Torex (Torex Group of Companies). If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. Torex Retail Solutions GmbH Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg. UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749. Geschaftsfuhrer: Stephen Callaghan, Martin Timmann. .
RE: How do I escape a subversion keyword?
How about:
if (length('$LastCheckedDate$') == 17) # keyword wasn't expanded
Regards,
Thomas
-Ursprüngliche Nachricht-
Von: Bob Archer [mailto:bob.arc...@amsi.com]
Gesendet: Freitag, 27. Mai 2011 19:08
An: dar...@chaosreigns.com; users@subversion.apache.org
Betreff: RE: How do I escape a subversion keyword?
I'm working on some software (spamassassin) that uses the
subversion
keyword $LastChangedDate$. In the same file that it's used, I
want that
string to appear unmodified - not expanded by subversion, exactly
as
$LastChangedDate$ instead of something like $LastChangedDate:
2010-03-30
08:02:18 -0400 (Tue, 30 Mar 2010) $
Because I want to check for a case where svn keywords aren't
getting
expanded.
Something like (perl):
if ('$LastChangedDate$' eq '$LastChangedDate$')
But with one of them getting expanded, and the other not.
I think it would work to do something like:
if ('$LastChangedDate$' eq '$LastChan'.'gedDate$')
But I'd prefer to escape the keyword instead.
Maybe something like \$LastChangedDate$ ?
I'm confused about what you are asking. Are you saying you don't want
subversion to expand the keywords? If so, then remove them from the
svn:keywords property. Any keywords not in the property are not expanded.
BOb
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions
expressed
are solely those of the author and do not necessarily represent those of Torex
(Torex Group of Companies). If you are not the intended recipient of this email
and its attachments, you must take no action based upon them, nor must you copy
or show them to anyone. Please contact the sender if you believe you have
received
this email in error.
Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.
.
Re: client crash on merge --reintegrate
Hello, It seems that the crash is related to improper preconditions for the reintegration, don't know what SVN wants to tell me there: client 1.6.15 crashes client 1.6.13 crashes client 1.6.12 doesn't crash but outputs an error message: cd trunk_wc svn merge --dry-run --reintegrate https://.../branches/... --accept postpone svn: Reintegrate can only be used if revisions 255131 through 265563 were previously merged from https://.../trunk to the reintegrate source, but this is not the case: .../branches/... Missing ranges: /.../trunk:264250-265543 .../branches/... Missing ranges: /.../branches/...:260111-260850 .../branches/... Missing ranges: /.../branches/...:213101-260850 .../branches/... Missing ranges: /.../branches/...:260826-260850 Missing ranges: /.../trunk/...:260811,260933 .../branches/... Missing ranges: /.../branches/...:260826-260850 Missing ranges: /.../trunk/...:260805-260811,260933 .../branches/... Missing ranges: /.../branches/...:260826-260850 Missing ranges: /.../trunk/...:260805-260811,260933 .../branches/... Missing ranges: /.../branches/...:174322-214515 Missing ranges: /.../trunk/...:103707-174319 Missing ranges: /.../branches/...:215928-236665 Missing ranges: /.../branches/...:236669-250022 Missing ranges: /.../branches/...:250348-260850 Missing ranges: /.../trunk/...:260933 Regards, Thomas -- Thomas Becker Software Development, Torex T: +49 (0)30 49901-0 E: thomas.bec...@torex.com Torex Retail Solutions GmbH, Salzufer 8, D-10587 Berlin T: +49 (0)30 49901-0 F: +49 (0)30 49901-139 www.torex.de Von: Becker, Thomas Gesendet: Mittwoch, 12. Januar 2011 16:58 An: 'users@subversion.apache.org' Betreff: client crash on merge --reintegrate Hello, When trying to reintegrate a branch into trunk the SVN client (version 1.6.15) crashed. It asked me to send the log file, so here it is. The server had version 1.6.5, upgrading the server to 1.6.15 didn't help. On the other hand, a client with version 1.6.12 didn't crash. Regards, Thomas Process info: Cmd line: svn merge --dry-run --reintegrate https://localhost:8443/svn/FMCG Version: 1.6.15 (r1038135), compiled Nov 24 2010, 15:10:31 Platform: Windows OS version 5.1 build 2600 Service Pack 3 Exception: ACCESS_VIOLATION Registers: eax= ebx=032f1640 ecx=000354ac edx= esi=0331a048 edi=0331a064 eip=100194c6 esp=0013fc34 ebp= efl=00210246 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= Stacktrace: #1 0x100194c6 in svn_client_merge_reintegrate () Loaded modules: 0x0040 C:\Program Files\Dev\Subversion Client\svn.exe (1.6.15.55095, 155648 bytes) 0x7c90 C:\WINDOWS\system32\ntdll.dll (5.1.2600.5755, 729088 bytes) 0x7c80 C:\WINDOWS\system32\kernel32.dll (5.1.2600.5781, 1007616 bytes) 0x6eec C:\Program Files\Dev\Subversion Client\libapr-1.dll (1.4.2.0, 139264 bytes) 0x77dd C:\WINDOWS\system32\advapi32.dll (5.1.2600.5755, 634880 bytes) 0x77e7 C:\WINDOWS\system32\rpcrt4.dll (5.1.2600.6022, 602112 bytes) 0x77fe C:\WINDOWS\system32\secur32.dll (5.1.2600.5834, 69632 bytes) 0x71ab C:\WINDOWS\system32\ws2_32.dll (5.1.2600.5512, 94208 bytes) 0x77c1 C:\WINDOWS\system32\msvcrt.dll (7.0.2600.5512, 360448 bytes) 0x71aa C:\WINDOWS\system32\ws2help.dll (5.1.2600.5512, 32768 bytes) 0x71a5 C:\WINDOWS\system32\mswsock.dll (5.1.2600.5625, 258048 bytes) 0x7c9c C:\WINDOWS\system32\shell32.dll (6.0.2900.6018, 8482816 bytes) 0x77f1 C:\WINDOWS\system32\gdi32.dll (5.1.2600.5698, 299008 bytes) 0x7e41 C:\WINDOWS\system32\user32.dll (5.1.2600.5512, 593920 bytes) 0x77f6 C:\WINDOWS\system32\shlwapi.dll (6.0.2900.5912, 483328 bytes) 0x1000 C:\Program Files\Dev\Subversion Client\libsvn_client-1.dll (1.6.15.55095, 204800 bytes) 0x6ee6 C:\Program Files\Dev\Subversion Client\libaprutil-1.dll (1.3.9.0, 192512 bytes) 0x6ee5 C:\Program Files\Dev\Subversion Client\libapriconv-1.dll (1.2.1.0, 36864 bytes) 0x0034 C:\Program Files\Dev\Subversion Client\libsvn_delta-1.dll (1.6.15.55095, 90112 bytes) 0x0043 C:\Program Files\Dev\Subversion Client\libsvn_subr-1.dll (1.6.15.55095, 716800 bytes) 0x7678 C:\WINDOWS\system32\shfolder.dll (6.0.2900.5512, 36864 bytes) 0x774e C:\WINDOWS\system32\ole32.dll (5.1.2600.6010, 1302528 bytes) 0x77a8 C:\WINDOWS\system32\crypt32.dll (5.131.2600.5512, 610304 bytes) 0x77b2 C:\WINDOWS\system32\msasn1.dll (5.1.2600.5875, 73728 bytes) 0x0036 C:\Program Files\Dev\Subversion Client\libsvn_diff-1.dll (1.6.15.55095, 53248 bytes) 0x0037 C:\Program Files\Dev\Subversion Client\libsvn_ra-1.dll (1.6.15.55095, 520192 bytes) 0x004e C:\Program Files\Dev\Subversion Client\libsvn_repos-1.dll (1.6.15.55095, 139264 bytes
client crash on merge --reintegrate
Hello, When trying to reintegrate a branch into trunk the SVN client (version 1.6.15) crashed. It asked me to send the log file, so here it is. The server had version 1.6.5, upgrading the server to 1.6.15 didn't help. On the other hand, a client with version 1.6.12 didn't crash. Regards, Thomas Process info: Cmd line: svn merge --dry-run --reintegrate https://localhost:8443/svn/FMCG Version: 1.6.15 (r1038135), compiled Nov 24 2010, 15:10:31 Platform: Windows OS version 5.1 build 2600 Service Pack 3 Exception: ACCESS_VIOLATION Registers: eax= ebx=032f1640 ecx=000354ac edx= esi=0331a048 edi=0331a064 eip=100194c6 esp=0013fc34 ebp= efl=00210246 cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= Stacktrace: #1 0x100194c6 in svn_client_merge_reintegrate () Loaded modules: 0x0040 C:\Program Files\Dev\Subversion Client\svn.exe (1.6.15.55095, 155648 bytes) 0x7c90 C:\WINDOWS\system32\ntdll.dll (5.1.2600.5755, 729088 bytes) 0x7c80 C:\WINDOWS\system32\kernel32.dll (5.1.2600.5781, 1007616 bytes) 0x6eec C:\Program Files\Dev\Subversion Client\libapr-1.dll (1.4.2.0, 139264 bytes) 0x77dd C:\WINDOWS\system32\advapi32.dll (5.1.2600.5755, 634880 bytes) 0x77e7 C:\WINDOWS\system32\rpcrt4.dll (5.1.2600.6022, 602112 bytes) 0x77fe C:\WINDOWS\system32\secur32.dll (5.1.2600.5834, 69632 bytes) 0x71ab C:\WINDOWS\system32\ws2_32.dll (5.1.2600.5512, 94208 bytes) 0x77c1 C:\WINDOWS\system32\msvcrt.dll (7.0.2600.5512, 360448 bytes) 0x71aa C:\WINDOWS\system32\ws2help.dll (5.1.2600.5512, 32768 bytes) 0x71a5 C:\WINDOWS\system32\mswsock.dll (5.1.2600.5625, 258048 bytes) 0x7c9c C:\WINDOWS\system32\shell32.dll (6.0.2900.6018, 8482816 bytes) 0x77f1 C:\WINDOWS\system32\gdi32.dll (5.1.2600.5698, 299008 bytes) 0x7e41 C:\WINDOWS\system32\user32.dll (5.1.2600.5512, 593920 bytes) 0x77f6 C:\WINDOWS\system32\shlwapi.dll (6.0.2900.5912, 483328 bytes) 0x1000 C:\Program Files\Dev\Subversion Client\libsvn_client-1.dll (1.6.15.55095, 204800 bytes) 0x6ee6 C:\Program Files\Dev\Subversion Client\libaprutil-1.dll (1.3.9.0, 192512 bytes) 0x6ee5 C:\Program Files\Dev\Subversion Client\libapriconv-1.dll (1.2.1.0, 36864 bytes) 0x0034 C:\Program Files\Dev\Subversion Client\libsvn_delta-1.dll (1.6.15.55095, 90112 bytes) 0x0043 C:\Program Files\Dev\Subversion Client\libsvn_subr-1.dll (1.6.15.55095, 716800 bytes) 0x7678 C:\WINDOWS\system32\shfolder.dll (6.0.2900.5512, 36864 bytes) 0x774e C:\WINDOWS\system32\ole32.dll (5.1.2600.6010, 1302528 bytes) 0x77a8 C:\WINDOWS\system32\crypt32.dll (5.131.2600.5512, 610304 bytes) 0x77b2 C:\WINDOWS\system32\msasn1.dll (5.1.2600.5875, 73728 bytes) 0x0036 C:\Program Files\Dev\Subversion Client\libsvn_diff-1.dll (1.6.15.55095, 53248 bytes) 0x0037 C:\Program Files\Dev\Subversion Client\libsvn_ra-1.dll (1.6.15.55095, 520192 bytes) 0x004e C:\Program Files\Dev\Subversion Client\libsvn_repos-1.dll (1.6.15.55095, 139264 bytes) 0x0051 C:\Program Files\Dev\Subversion Client\libsvn_fs-1.dll (1.6.15.55095, 135168 bytes) 0x0054 C:\Program Files\Dev\Subversion Client\libeay32.dll (1.0.0.2, 1286144 bytes) 0x0068 C:\Program Files\Dev\Subversion Client\ssleay32.dll (1.0.0.2, 245760 bytes) 0x006c C:\Program Files\Dev\Subversion Client\libsasl.dll (2.1.23.0, 77824 bytes) 0x006e C:\Program Files\Dev\Subversion Client\libsvn_wc-1.dll (1.6.15.55095, 217088 bytes) 0x7639 C:\WINDOWS\system32\imm32.dll (5.1.2600.5512, 118784 bytes) 0x773d C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df _6.0.2600.6028_x-ww_61e65202\comctl32.dll (6.0.2900.6028, 1060864 bytes) 0x5d09 C:\WINDOWS\system32\comctl32.dll (5.82.2900.6028, 630784 bytes) 0x5ad7 C:\WINDOWS\system32\uxtheme.dll (6.0.2900.5512, 229376 bytes) 0x7472 C:\WINDOWS\system32\MSCTF.dll (5.1.2600.5512, 311296 bytes) 0x71f8 C:\WINDOWS\system32\security.dll (5.1.2600.5512, 16384 bytes) 0x77c7 C:\WINDOWS\system32\msv1_0.dll (5.1.2600.5876, 151552 bytes) 0x7679 C:\WINDOWS\system32\cryptdll.dll (5.1.2600.5512, 49152 bytes) 0x76d6 C:\WINDOWS\system32\iphlpapi.dll (5.1.2600.5512, 102400 bytes) 0x6800 C:\WINDOWS\system32\rsaenh.dll (5.1.2600.5507, 221184 bytes) 0x754d C:\WINDOWS\system32\cryptui.dll (5.131.2600.5512, 524288 bytes) 0x5b86 C:\WINDOWS\system32\netapi32.dll (5.1.2600.5694, 348160 bytes) 0x7712 C:\WINDOWS\system32\oleaut32.dll (5.1.2600.5512, 569344 bytes) 0x77c0 C:\WINDOWS\system32\version.dll (5.1.2600.5512, 32768 bytes) 0x3d93 C:\WINDOWS\system32\wininet.dll (7.0.6000.17091, 856064 bytes) 0x0117 C:\WINDOWS\system32\normaliz.dll (6.0.5441.0, 36864 bytes) 0x3dfd C:\WINDOWS\system32\iertutil.dll (7.0.6000.17091, 282624 bytes) 0x76c3 C:\WINDOWS\system32\wintrust.dll (5.131.2600.5922, 188416 bytes) 0x76c9
