VBS, JS: Проблемы с CreateObject("Shell.Application").Windows().Count

Не помогает, причем уже на 2 компьютерах проверил.

На одном компьютере
Windows XP SP3
WSH v5.7
IE 8

На домашнем
Windows XP SP2
WSH v5.6
IE 7

Да ну :

Set objShellApp = CreateObject("qww.qww")

Вы путаете с «WScript.CreateObject()»:

Set objShellApp = WScript.CreateObject("qww.qww")

jite, так и у меня работает. А у коллеги DnsIs — нет.

Это точно не работает на локальном компе под WSH?
А то может на ISS (ASP)? Или попытка запуска CreateObject() на другом компе?

Если точно локально, под WSH, то:
1) Идем в свойства обозревателя IE и во вкладке безопасность проверяем, не слишком ли высок ее уровень... э-э для локального компа уровня нет (вообще-то это ветка HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0), но может поможет сброс движков доверенных и интранета в "Средний"? После перегрузиться для гарантии.
2) Или создаем нового пользователя, даем для гарантии ему права локального админа, смотрим, как под ним? Если под новым все ОК, то под "нерабочим" профилем есть проблема в упомянутой ветке реестра.

jite, настройки IE у меня по-умолчанию.
Но обнаружил вот что:
Оказывается, что скрипт, прекрасно пашет если его запустить из проводника windows (0)
НО! Если из Total Commander (1), Notepadd++ (2) или из консоли (3), то не хочет запускаться ни в какую.
Проверил строки запуска скрипта, но во всех случаях они оказались идентичными, символ в символ.

Тогда я проверил от имени какого пользователя запускаются процессы, оказалось что
(1), (2), (3), запускают WScript.exe от имени SYSTEM,
А (0) от имени локального пользователя.
О как!

Я думаю, проще будет сделать загрузку TC и прочего из обычного пользовательского раздела «HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run». Горячие клавиши и прочее удобно организовывать в «True Launch Bar».

Это лучшее решение.

Ну если точней, то это аккаунт (SYSTEM он же NT AUTHORITY\SYSTEM), под которым собственно операционка "логинится" и действует. Уровень полномочий SYSTEM примерно такой же, как и у встроенного админа. Именно для него во вкладке безопасность предусмотрены права доступа SYSTEM.
Однако под SYSTEM лучше не сидеть лично и повседневно - не предназначен он для этого. Наверняка найдутся какие-нибудь специфические грабли, для обхода которых придется менять настройки ОС по ум. с риском чего-нибудь непоправимо сломать. Оно нам надо?
Из полезного же можно зайти под ним не переопределяя прав на папки:
- в "System volume information" - актуально при лечении небольших сбоев привязки к жесткому, как правило, требуется в XP после клонирования диска,
- в кэш автономных файлов C:\Windows\CSC - актуально для Win7, папка известна тем, что со временем в ней накапливается много мусора, который просто так не удалить.
Словом специфические операции.

Еще одно специфическое применение аккаунта. Кто бы мог подумать, куда может завести обсуждение неработающей функции...

Возвращаясь к теме. Все-таки интересно, почему же SYSTEM не имеет права получать Shell.Application? А если я вдруг задумаю под этим акком какой-нибудь скрипт выполнить? Что, разве не должен выполниться? Странно.

off (bytheway system_purpose)

Вообще-то упомянутая ветка доступна для чтения всем... если я случайно не сбросил разрешения.
В статье же говорится про %SystemRoot%\system32\config\SAM, а его при активной ОС прочесть не удастся и под SYSTEM. Впрочем он читается другими способами. Даже при активной ОС.

end off

jite, да да, как правильно поправил alexii, я имел ввиду ветку «HKEY_LOCAL_MACHINE\SAM\SAM».
А вы уверены что читается? Вы открываете ее, а там пусто или нет? Если пусто то вы просто ничего не видите. Попробуйте так:

at 0:43 reg export HKEY_LOCAL_MACHINE\SAM\SAM c:\reg.reg

Вместо 0:43 подставьте свое время

и потом загляните в полученный файл.

Ну а про %SystemRoot%\system32\config\SAM в манах написано:

Так что фактически одно и тоже.

Не подскажите как?

2jite: коллега, при ссылке на Google (хоть этого и нет в Правилах ) желательно (и, думаю, достаточно) давать уже сформулированный запрос, например так, или так, иначе это не может считаться ответом на вопрос.

В какой его части?

А, Вы для данного конкретного случая… Понятно. Пост уже не стану удалять, дабы не терялась нить рассуждений, почему в данном случае нельзя. Спасибо, ясно.

Уважаемый DnsIs, я тоже не отношусь к деструктивной категории разработчиков. И в отличие от вас даже не практиковал ассемблер. Вирусными технологиями интересуюсь и сейчас - с точки зрения защиты,- как и любой другой, связанный с системным администрированием.
Вполне готов поделиться сведениями на эту тему, просто здесь это не рекомендовано...

------------------ >8 Линия отреза 8< ------------------

this.topic_title.new("ЛС как альтернативный способ обсуждения нерекомендованного к обсуждению. Вопросы, тестирование")

Плюнте в меня если я не прав, но я считаю, что тема прямым образом не относиться в вирусописательству. Раз уж так, то давайте запретим писать на форумах "format c:", "del c:\windows\*.*" и пр...
Необязательно писать о фале SAM. Тем более в интернете полно статей на эту тему.
Неужели ни у кого не возникает необходимости копировать залоченные файлы. А SAM ведь, как я понимаю не исключение.

У меня на работе каждый день бэкапится база 1с "на живую".
Самый очевидный из способов, это использование программ задействующих, вполне легальное и документированное Теневое копирование. Наверняка все админы про него знают.

Нужно учитывать и тот факт, что у большинства (по крайней мере из моих личных наблюдений) е-почта является всего лишь обязательной принадлежностью каждого для зарегистрирования аккаунтов, учитывая то обстоятельство, что существуют гораздо удобнее средства общения (аськи-ирки, контакты-одноклассники..) и обмена информации (файлообменники, виртуальные флешки и т.д. и т.п.) чем е-почта.

Мне кажется нужно временные ящики (Mailinator.com и пр.) фильтровать, нафик такие пользователи нужны.

Ну и как, получили письмо?

OFF: Тьфу ты! Письмо-то не мне было отправлено. Недоглядел .