나름 최신의 Intel 프로세스 기반 노트북을 구입했습니다.

데스크톱에서는 아무런 문제가 없던 무선 마우스(MX Master 3)와 키보드가 버벅거림이 없어지지 않고 사용하다 멈추고, 다시 풀리고... 엄청 힘들게 하더군요.

문제는 Intel 최신 노트북 기준에서 매우 흔하게 나타나는 증상입니다.

그런데 그런 글을 따라 해도 잠시 해결되더니 다시 현상이 반복.

 

아래처럼 USB 허브의 전원 관리 옵션을 수정해서 해결 완료했습니다.

요약하면 마우스, 키보드가 물려 있는 USB 허브의 전원 관리 해제하는 것!

 

 

1. Window key + X  누르고, 장치 관리자를 선택

 

2. 장치 관리자 - 버벅거리고 있는 마우스 선택 (그런데 어느 마우스? 아래 3에서 확인)

 

3. 마우스 각각을 선택 후 '이벤트' - 정보 부분에 보이는 VID_XXX 부분을 기억

모든 마우스에 대해 확인(별도 기록 해 두세요), 마우스를 뽑습니다(혹은 무선 마우스 어댑터 뽑기)

그리고 앞서 기록 해 둔 정보 부분과 비교하여 대상 마우스를 선택합니다.

 

4. 대상 마우스(HID 규격 마우스) 선택 상태에서, 아래처럼 '보기'메뉴에서 '연결 별 디바이스' 선택합니다.

 

 

5. 아래처럼 Tree 형태로 표시됩니다.

 

6. 상위에 위치한 'USB 허브'를 찾아 선택합니다.

이번 예시에서는 '일반 USB 허브' 선택

 

7. Enter 혹은 마우스 더블 클릭으로 속성을 열고, '전원 관리'탭을 선택

마지막으로 [v]전원을 절약하기 위해 컴퓨터가 이 장치를 끌 수 있음(A) 을 선택하여 check를 없앱니다. 

아래처럼 만들면 됩니다.

 

고생하셨습니다. 이제 끊김 없는 마우스, 키보드 사용을 ~

 

** 저는 동일 허브로 무선 마우스, USB 키보드를 연결했기에 무선 마우스가 물린 허브만 찾아서 모두 해결했습니다.


집에서 java app.을 실행 하려 했더니 실행 즉시 app.이 닫혀 버리는 증상이 확인 되었습니다.

해당 app.을 다른 컴퓨터(Windows 7 구동)에서는 정상 작동 하는 것을 확인 했던 것이라 매우 이상한 상황!


Java crash log의 핵심만 요약 하면 아래와 같습니다.

. . .

# A fatal error has been detected by the Java Runtime Environment:

#

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000062146adf, pid=8912, tid=0x00000000000009b8

#

# JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b11)

# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode windows-amd64 compressed oops)

# Problematic frame:

# C  [msvcr100.dll+0x36adf]


. . .

. . .


Stack: [0x000000001f680000,0x000000001f780000],  sp=0x000000001f77ecc8,  free space=1019k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C  [msvcr100.dll+0x36adf]


Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

J 2701  sun.awt.shell.Win32ShellFolder2.getDisplayNameOf(JJI)Ljava/lang/String; (0 bytes) @ 0x00000000028412c9 [0x0000000002841280+0x49]

j  sun.awt.shell.Win32ShellFolder2.access$1600(JJI)Ljava/lang/String;+4

j  sun.awt.shell.Win32ShellFolder2$13.call()Ljava/lang/String;+15

j  sun.awt.shell.Win32ShellFolder2$13.call()Ljava/lang/Object;+1

J 1987 C1 java.util.concurrent.FutureTask.run()V (126 bytes) @ 0x0000000002d4764c [0x0000000002d47400+0x24c]

. . .

. . .


결론은 아래의 bug report를 보면 되는데.

요약 하면 Windows 10 최신 update로 인하여 GOD mode를 설정한 폴더명이 NULL 로 처리 되어 java awt내부 code에서 crash를 일어키는 현상 입니다.

MS를 미워할 수는 없는것이 결국 java에서 exception handling을 안해서 여서...


그런데 수정 내용을 보니, 원 Java 9에서만 수정 반영 했다는 것! 

Java 8은 그냥 쌩....


그래서 해결 방법은 만일 바탕화면에 GOD mode 설정한 폴더가 있다면 (이름이 없습니다) 이것을 삭제 하거나 다른 폴더로 이동 후 java app.을 실행 하면 됩니다.


Java 9 을 사용할 계획이 없다면 가장 적절한 선택일 것 같습니다.


위 내용에 대한 java bug report는 아래 URL에서 확인 가능 합니다.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8179014


관련 사항은 아래와 같이 여러 리포트가 있습니다.

Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:


이로서 Bug는 가만히 있어도 (남들에 의해서) 만들어 진다는 진리? 를 아주 큰 S/W 기업에서도 확인이 되었네요^^ (그렇다고 엄청난 예외 code를 넣는 것도 쉽지 않으니)


보너스~ 해당 문제 해결 code 변경 사항은 아래와 같습니다.

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a7c8147f1891


files src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp test/javax/swing/JFileChooser/GodMode/JFileChooserTest.java

--- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp	Tue May 09 12:19:08 2017 -0700
+++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp	Thu May 11 12:41:35 2017 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -205,14 +205,19 @@
 static jstring jstringFromSTRRET(JNIEnv* env, LPITEMIDLIST pidl, STRRET* pStrret) {
     switch (pStrret->uType) {
         case STRRET_CSTR :
-            return JNU_NewStringPlatform(env, reinterpret_cast<const char*>(pStrret->cStr));
+            if (pStrret->cStr != NULL) {
+                return JNU_NewStringPlatform(env, reinterpret_cast<const char*>(pStrret->cStr));
+            }
+            break;
         case STRRET_OFFSET :
             // Note : this may need to be WCHAR instead
             return JNU_NewStringPlatform(env,
                                          (CHAR*)pidl + pStrret->uOffset);
         case STRRET_WSTR :
-            return env->NewString(reinterpret_cast<const jchar*>(pStrret->pOleStr),
-                static_cast<jsize>(wcslen(pStrret->pOleStr)));
+            if (pStrret->pOleStr != NULL) {
+                return env->NewString(reinterpret_cast<const jchar*>(pStrret->pOleStr),
+                    static_cast<jsize>(wcslen(pStrret->pOleStr)));
+            }
     }
     return NULL; 

} 


즐 개발 / 즐 컴퓨팅 되시길~


부팅은 물론이고 잦은 최대 절전모드(Hibernation) 속도를 최대한 빨리 하기 위해 드디어 950 PRO를 구입했습니다.


사진 몇장과 간단한 사용 느낌을 기록 합니다.

상세 내용과 여러 벤치마크는 인터넷에서 검색하면 상세 내용을 쉽게 찾을 수 있으니 전 실사용 결과 한줄 요약을 하겠습니다.


이전 사용 SSD가 840 EVO (250G)인 관계로 최대 절전모드 진입과 복구에 적지 않은 시간이 걸렸습니다. 기억으로 20초 조금 넘는 수준... 아 물론 840 EVO 문제는 patch 처리한 상태로 사용 중이라 문제의 840 EVO 현상은 배제한 상태 입니다. 사용 OS = Windows 10. , EFI booting


950 PRO 가격이 일정 수준 내려 오지 않고 더 싸게 구입할 경로도 없고 해서 결국 시장 가격 수준으로 구입 했네요.


기존 SSD가 250G 모델이라 950 PRO 512G 모델로의 전환은 비교적 쉬웠습니다.

1. Z170 보드의 그래픽 카드 설치 위치 아래의 M.2 슬롯에 설치

위치가 딱 그래픽 카드 바로 밑이라 그래픽 카드는 필수로 뽑았다 넣어야 합니다.

고정 지지대+볼트는 마더보드 업체에서 제공하는 것을 그대로 이용 했습니다. 알고 보니 머리와 하단 지지대가 분리 되는 형태... 


2. 부팅 후 기존 SSD -> 950 PRO로의 마이그레이션 - 업체에서 제공하는 Migration tool로 한번에 완료.


3. 기존 SSD 뽑아내고 부팅 확인. (BIOS 설정은 알아서 조절 필요)



부팅, 절전모드 진입 복구 속도가 정말 빨라 졌을까?

확인결과: 기존 SSD에 비해 절반에 가까운 약 12초 전후(11초~13초)로 부팅/복원

결론: 최대 절전모드를 자주 사용하는 사용자에게 적극 추천!

키보드 드라이브 활성 보다 부팅이 먼저 완료 되어서 로그인은 12초 안에 할 수 없는 경우가 많네요^^


사진 몇장 (2048px) 나갑니다~ 







012345





+ Recent posts