Sambutan Aidil Fitri 2009
2. Majlis Sambutan Hari Raya Aidil Fitri di Pullman Hotel, Putrajaya - 2009.
Walimatul Urus anak Brader Zukree, 2010
4. Perkahwinan anak perempuan Zukree di Bukit Beruntung Golf Club.
Mesyuarat Agung 2012
Intake 7 bersama Tuan Presiden Persatuan selepas Mesyuarat Agung AFATS di Kelab Shah Alam, 2012.
Sunday, January 31, 2016
Wednesday, January 27, 2016
Inna lillahi wa inna ilayhi raji'un
- ALLAHYARHAM ALLAHYARHAM INTAKE 7
- Semoga Allah SWT menempatkan mereka bersama para solihin dan syuhada... aaminn
Inna lillahi wa inna ilayhi raji'un
BIL. | NO. TENTERA | NAMA ALLAHYARHAM | TAHUN |
---|---|---|---|
1. | 530372 | ROSLI BIN OTHMAN | 2016 |
2. | 530419 | KATAMI BIN HASSAN | 2014 |
3. | 530413 | KAMAL BIN ISMAIL | 2012 |
4. | 530370 | KHALID BIN HASHIM | 2003 |
5. | 530395 | ISMAIL BIN TAOHID | 1986 |
6. | 530398 | RUZLAM BIN MAMAT | 2002 |
7. | 530413 | AZMI BIN AHMAD | 1981 |
8. | 530414 | RAMLI BIN SHAFIE | 1979 |
9. | 530397 | IBRAHIM BIN MOHAMMAD | 1978 |
Monday, January 18, 2016
MISI ZIARAH SKOT 530382 APP FADZIL BIN AHMAD
Suasana ketika menziarahi Fadzil dikediamannya...indah sungguh suasana kampung, tali air, sawah padi dan gunung ganang..nyaman udara
Really lovely atmosphere at his village
Delivering Jacket and donations from G7 to Fadzil on 18th Jan 2016 at 3.30 pm at his residence in Kg Telaga Tengah, Mukim Gunung, Kedah.
Really lovely atmosphere at his village
Our latest face app 530382 Skot Fadzil Bin Ahmad...
The Picture in his residence in kg keneriang, Mukim Gunong, Kedah on
18th Jan, 2016
Delivering Jacket and donations from G7 to Fadzil on 18th Jan 2016 at 3.30 pm at his residence in Kg Telaga Tengah, Mukim Gunung, Kedah.
- LAPORAN ZIARAH DAN LAWATAN 530382 APP FADZIL BIN AHMAD :
- MUKADDIMAH :
- Seramai 4 orang Skot G7 telah melakukan ziarah dan lawatan keatas Fadzil bin Ahmad pada 18hb Januari, 2016 [ Ahad ] di Kg Telaga Tengah, Mukim Gunung, Alor Star, Kedah. Rombongan G7 terdiri daripada 530386 Roslan Md Din, 530387 Arif Isa, 530412 Rauf Mohd dan 530416 Zambri.
- HASIL LAWATAN :
- Pihak rombongan mendapati Fadzil Ahmad hidup dalam keadaan serba sederhana [ dalam asnaf fakirmiskin ] tinggal dijauh pendalaman kampung yang dikelilingi sawah bendang...Beliau boleh dikategorikan tidak FAKIR dan TIDAK BEGITU SENANG...hidup kais pagi makan pagi dan cukup makan..tidak mempunyai harta atau tanah..hanya tinggal di tanah pesaka arwah ayahnya. Beliau telah tidak bekerja hampir 3 tahun atas sebab kesihatan yang beliau alami. Beliau berkahwin dan mempunyai 7 orang anak. Dua orang anaknya telah bekerja dan 5 masih bersekolah dari Tingkatan 6 hingga Tahun 1. Dua daripada anaknya tinggal di asrama. Beliau kini hanya menjalankan kerja kerja sambilan seperti mengambil upah membawa lori beras ketika musim padi. Pekerjaan ini adalah pekerjaan bermusim dan beliau sebagai tok siak dimasjid berdekatan dengan mendapat elaun dari pihak masjid tersebut. Manakala isteri beliau adalah seorang suri rumahtangga sepenuh masa dan mengambil upah menjahit atas sumbangan dari jabatan kebajikan masyarakat. Beliau hanya mendapat bantuan dari Majlis Agama Islam Negeri Kedah sebanyak RM 100.00 sebulan. Selain itu beliau tidak mendapat bantuan dari mana-mana pihak terutama dari pihak Veteran mahupun Bekas Perajurit disebabkan latarbelakang beliau ketika berkhidmat dahulu...
- KESIMPULAN :
- Masih boleh lagi berdikari dan tidak hidup melarat dan dengan pendapatan serba sederhana. Setiap sumbangan yang diterina atau diberikan adalah sebagai satu bonus atau kelebihan untuk keluarga beliau. wallahuallam
Sunday, January 17, 2016
Sunday, January 10, 2016
SEORANG LAGI SAHABAT TELAH KEMBALI KE RAHMATULLAH
Inna lillahi wa inna ilayhi raji'un
Dimaklumkan bahawa Rosli Bin Othman (530372) telah kembali ke rahmatullah pada pagi Sabtu, 09.01.2016.
Jenazah telah dimandi dan dikapan di Hospital Angkatan Tentera Tuanku Mizan, Wangsa Maju.
Jenazah kemudian telah dibawa ke masjid Al-Mukminun di USJ 2 untuk disolat dan urusan pengebumian.
Berikut beberapa catatan daripada WhatsApp G7 :
Dimaklumkan bahawa Rosli Bin Othman (530372) telah kembali ke rahmatullah pada pagi Sabtu, 09.01.2016.
Jenazah telah dimandi dan dikapan di Hospital Angkatan Tentera Tuanku Mizan, Wangsa Maju.
Jenazah kemudian telah dibawa ke masjid Al-Mukminun di USJ 2 untuk disolat dan urusan pengebumian.
Berikut beberapa catatan daripada WhatsApp G7 :
- "Sebagai khidmat terakhir pada sahabat kita, G7 telah membuat kutipan derma kilat"
- "Allahyaram telah selamat disemadikan di tanah perkuburan Islam USJ 2 pada jam 1455. Semoga Allah SWT mencucuri rahmat roh beliau, aaminn."
- "Ariff telah dapat berhubung dengan abang Arwah iaitu Mazlan Othman dimana beliau amat terharu di atas keperihantinan sahabat-sahabat Arwah dalam membantu arwah selama ini sehingga ke perkuburan... Beliau merakamkan ucapan terima kasih."
- Terima kasih juga kepada sahabat-sahabat (Zainal, Hilal dan Mustafa) yang telah mengiringi jenazah sehingga ketanah perkuburan.
Wednesday, January 06, 2016
TABUNG AMAL JARIAH
SUMBANGAN UNTUK TABUNG AMAL JARIAH 0382
29.12.2015 :
30.12.2015 :
31.12.2015 :
01.01.2016 :
02.01.2016 :
03.01.2016 :
04.01.2016 :
05.01.2015 :
06.01.2016 :
ialah RM 3,255.00...pada skot yg menderma pihak G7 merakamkan ucapan Jazakallah khairan kathira.
29.12.2015 :
1. | RM | 50.00 |
2. | RM | 50.00 |
1. | RM | 240.00 |
2. | RM | 240.00 |
3. | RM | 140.00 |
4. | RM | 100.00 |
5. | RM | 40.00 |
6. | RM | 50.00 |
7. | RM | 100.00 |
8. | RM | 60.00 |
9. | RM | 225.00 |
10. | RM | 90.00 |
11. | RM | 50.00 |
12. | RM | 50.00 |
1. | RM | 100.00 |
2. | RM | 80.00 |
1. | RM | 200.00 |
2. | RM | 50.00 |
1. | RM | 90.00 |
2. | RM | 100.00 |
3. | RM | 50.00 |
1. | RM 50.00 |
1. | RM 50.00 |
1. | RM | 50.00 |
2. | RM | 240.00 |
3. | RM | 70.00 |
4. | RM | 50.00 |
1. | RM 60.00 |
2. | RM 50.00 |
- JUMLAH TERKINI 07.01.2016 = RM 2,805.00
- Untuk maklumat G7...selain kutipan dibuat di group ini..terdapat G7 yang memberikan sumbangan secara terus kepada beliau...maklumat dari Fadzil sendiri. :
- RM 300.00
- RM 100.00
- RM 50.00
ialah RM 3,255.00...pada skot yg menderma pihak G7 merakamkan ucapan Jazakallah khairan kathira.
Monday, January 04, 2016
Windows XP SVCHOST.EXE, WUAUCLT.EXE CPU 100% Fix
If you’re an Independent Technology Professional like me, you are probably still working a lot with Windows XP. Let’s face it: for everything Microsoft is doing to move users to newer versions of Windows, Windows XP is simply entrenched in the marketplace and will probably continue to be for at least a few more years. The reality is there are a lot of people and business out there who run older Windows software and do not need to move to newer versions of Windows – especially now that Windows 8 is scaring the pants off people.
A lot of my clients still run Windows XP, especially those who bought PCs after 2007 and did their best to avoid Windows Vista. Yes, their machines are old, but with a little TLC they continue to run well for them and they aren’t interested in upgrading their PCs for the time being. Additionally, for several years now I’ve been heavily involved in setting up computers with Windows XP running in a virtual machine, whether it is for new Macintosh users who still need to run a particular Windows-only software, or Windows 7 or 8 users who need compatibility with older software. In the last year I kept running into a tricky issue I couldn’t quite squash because of its transient nature. But after a lot research I finally found the root cause and a possible solution. I began to see this problem a lot as I was setting up brand new Windows XP SP3 installations under virtual machine software, whether that software was VirtualBox, Parallels, Virtual PC, Hyper-V, or others on either Macintosh or Windows host computers. It seemed to me like running the several rounds of updates after the initial Windows XP installation was taking forever – significantly longer than the usual lengthy process. Investigating the issue, I noticed that a SVCHOST.EXE process was eating up all the CPU. Further investigation showed that WUAUCLT.EXE was the core process behind the particular SVCHOST.EXE process. WUAUCLT.EXE is the Windows Update Automatic Update Client software that obviously manages automatic updates. What I observed, however, was that the problem really only manifested itself noticeably during the initial rounds of updates after the Windows XP install. The problem appeared to go away after that so I didn’t bother to troubleshoot it further. However, I later did start to observe the issue on client machines that were not brand-new Windows XP installs. I also noticed that that the problem seemed to intermittently return on the Windows XP installs that I had set up in virtual machines. After troubleshooting a few cases independently, I realized there was a common thread between all of them. Obviously there is a problem with the Windows Update Automatic Update Client. Woody Leonhard from InfoWorld.com has done the best job of explaining the cause of the SVCHOST problem that I’ve found anywhere. Apparently, this problem has been in existence in various forms for many years. However, it seems to have gotten a lot worse lately. The simple explanation is that Microsoft believes that the amount of old updates in the automatic update chain has gotten to the point where it is overwhelming the WUAUCLT.EXE process. Microsoft is working to fix the problem but it seems that successive attempts have had mixed results. Based on my research, I believe I have found the general process for resolving the issue. When I first started investigating this issue heavily a few months ago, the fix I found involved installing MS13-080/KB 2879017, which was released in October 2013. Ironically this patch is described as a Cumulative Security Update for Internet Explorer and does not mention fixing Windows Update Automatic Update Client. This did seem to fix the issues I was working on at the time. Later, however, it appeared that this fix no longer worked. It seemed that there were new Cumulative Security Updates for Internet Explorer. First came MS13-088/KB2888505 in November, followed by MS13-097/KB 2898785 in December. At the time of this writing, MS13-097/KB 2898785 seems to be the magic bullet for most situations. That being said, given the history of this issue, I would not be surprised if we see the problem re-emerge when the next Cumulative Security Update for Internet Explorer is released. I will update the article if/when this problem returns and/or if Microsoft finally fixes the root cause of the issue on their end. For brand new Windows XP SP3 installs, where the SVCHOST problem rears its ugly head almost immediately, I have confirmed that manually installing MS13-097/KB 2898785 fixes the issue. Running Windows Update or Automatic Updates proceeds normally and in fact, is much quicker than it has seemed in years. Likely we have been experiencing this issue for a long time and simply chalked it up to Windows Updates being slow in general. Oh, the wasted hours! On deployed machines, if you’re lucky the Cumulative Security Update for Internet Explorer will be installed by Automatic Updates. Likely this is what is happening for most people that have Automatic Updates turned on and they simply never notice the slowdown that SVCHOST causes. However, if you run into this issue in the field, it can be very time consuming to run Windows Updates since the SVCHOST problem makes the computer run like molasses. In this situation, you should kill the SVCHOST.EXE process in Task Manager which will then free up the computer’s CPU so that you can quickly manually download and install the update. After restarting, you may notice that SVCHOST still spikes the CPU when Windows is searching for updates, but it should be brief and the effect should be negligible. Windows XP SVCHOST.EXE, WUAUCLT.EXE CPU 100% Fix
A lot of my clients still run Windows XP, especially those who bought PCs after 2007 and did their best to avoid Windows Vista. Yes, their machines are old, but with a little TLC they continue to run well for them and they aren’t interested in upgrading their PCs for the time being. Additionally, for several years now I’ve been heavily involved in setting up computers with Windows XP running in a virtual machine, whether it is for new Macintosh users who still need to run a particular Windows-only software, or Windows 7 or 8 users who need compatibility with older software. In the last year I kept running into a tricky issue I couldn’t quite squash because of its transient nature. But after a lot research I finally found the root cause and a possible solution. I began to see this problem a lot as I was setting up brand new Windows XP SP3 installations under virtual machine software, whether that software was VirtualBox, Parallels, Virtual PC, Hyper-V, or others on either Macintosh or Windows host computers. It seemed to me like running the several rounds of updates after the initial Windows XP installation was taking forever – significantly longer than the usual lengthy process. Investigating the issue, I noticed that a SVCHOST.EXE process was eating up all the CPU. Further investigation showed that WUAUCLT.EXE was the core process behind the particular SVCHOST.EXE process. WUAUCLT.EXE is the Windows Update Automatic Update Client software that obviously manages automatic updates. What I observed, however, was that the problem really only manifested itself noticeably during the initial rounds of updates after the Windows XP install. The problem appeared to go away after that so I didn’t bother to troubleshoot it further. However, I later did start to observe the issue on client machines that were not brand-new Windows XP installs. I also noticed that that the problem seemed to intermittently return on the Windows XP installs that I had set up in virtual machines. After troubleshooting a few cases independently, I realized there was a common thread between all of them. Obviously there is a problem with the Windows Update Automatic Update Client. Woody Leonhard from InfoWorld.com has done the best job of explaining the cause of the SVCHOST problem that I’ve found anywhere. Apparently, this problem has been in existence in various forms for many years. However, it seems to have gotten a lot worse lately. The simple explanation is that Microsoft believes that the amount of old updates in the automatic update chain has gotten to the point where it is overwhelming the WUAUCLT.EXE process. Microsoft is working to fix the problem but it seems that successive attempts have had mixed results. Based on my research, I believe I have found the general process for resolving the issue. When I first started investigating this issue heavily a few months ago, the fix I found involved installing MS13-080/KB 2879017, which was released in October 2013. Ironically this patch is described as a Cumulative Security Update for Internet Explorer and does not mention fixing Windows Update Automatic Update Client. This did seem to fix the issues I was working on at the time. Later, however, it appeared that this fix no longer worked. It seemed that there were new Cumulative Security Updates for Internet Explorer. First came MS13-088/KB2888505 in November, followed by MS13-097/KB 2898785 in December. At the time of this writing, MS13-097/KB 2898785 seems to be the magic bullet for most situations. That being said, given the history of this issue, I would not be surprised if we see the problem re-emerge when the next Cumulative Security Update for Internet Explorer is released. I will update the article if/when this problem returns and/or if Microsoft finally fixes the root cause of the issue on their end. For brand new Windows XP SP3 installs, where the SVCHOST problem rears its ugly head almost immediately, I have confirmed that manually installing MS13-097/KB 2898785 fixes the issue. Running Windows Update or Automatic Updates proceeds normally and in fact, is much quicker than it has seemed in years. Likely we have been experiencing this issue for a long time and simply chalked it up to Windows Updates being slow in general. Oh, the wasted hours! On deployed machines, if you’re lucky the Cumulative Security Update for Internet Explorer will be installed by Automatic Updates. Likely this is what is happening for most people that have Automatic Updates turned on and they simply never notice the slowdown that SVCHOST causes. However, if you run into this issue in the field, it can be very time consuming to run Windows Updates since the SVCHOST problem makes the computer run like molasses. In this situation, you should kill the SVCHOST.EXE process in Task Manager which will then free up the computer’s CPU so that you can quickly manually download and install the update. After restarting, you may notice that SVCHOST still spikes the CPU when Windows is searching for updates, but it should be brief and the effect should be negligible. Windows XP SVCHOST.EXE, WUAUCLT.EXE CPU 100% Fix